apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Inherited Handles and APR
Date Sat, 14 Jul 2001 07:06:54 GMT
Anyone care to apply this to unix and hack it a bit?  I only found four cases where
we (probably) should be calling apr_file_open() to create an inheritable file.

As I mention, sockets are still an issue, so are child processes, shared memory
handles, and a list of others.  But if we knock these off one bit at a time, we will
probably knock down the child handle abuse.

Serious (?) bug I noticed, if a buffered file has pending data to write, and a child
is spawned, both the parent _AND_ child will attempt to flush the buffer.  It used
to happen when the child pool was destroyed, with this patch it will occur when the
process is spawned.  It appears we need a pre-fork() registered action, to flush
buffers and the like.  That's only partially effective though, unless we do some
heavy mutex protection :(

I'm still traveling till Sunday morning, so I can't revisit for a bit.

----- Original Message ----- 
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@apr.apache.org>
Sent: Friday, July 13, 2001 3:45 PM
Subject: Inherited Handles and APR

> After a respectable lunch at Boudin's, Ryan and I think we have the general answers
> to child handles.
> The apr_foo_open/create calls need an APR_INHERIT flag bit to mark resources as
> inheritable.  This offers two advantages;
>   1. the app doesn't need to worry about fork/exec cleanups v.s. inherit bits for
>      createprocess() based Win32 (and other non-forks.)
>   2. mainline code is more readable, as the user no longer registers their own
>      cleanup_for_exec handlers to simply close handles.
> The patch, for apr_file_open, follows.  Rbb is working on a similar for Sockets, and
> calls that generate 'handles' will need to be reviewed as well...
> I obviously have the much larger job of applying the APR_INHERIT flag judiciously
> throughout the entire server and removing child cleanups where appropriate ...
> Bill

View raw message