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 [Patch rev 3] FD_CLOEXEC and APR_INHERIT
Date Wed, 19 Mar 2003 05:18:12 GMT
Thanks to the feedback from Joe and Bjoern, I have committed a ton and 1/2 
of bug fixes to apr's open.c and dupfile.c.

After those changes, this patch is much easier to read.  Please take a look
and comment on anything you see that might be amiss.

If there are ANY remaining bugs in the current implementation of APR_INHERIT
(ignoring the non-apr fork()/exec() issues that this patch addresses now) they
should be fixed immediately.

I reserve my extreme opinions for Win32 matters, I won't express any opinion
on wether or not this patch should be in 0.9.2.  I offer it for completeness.
Provided the developer is using apr_proc_create, today they should end up
with no unintended handles in Unix child processes from our apr_file_t or
apr_socket_t entities.  If this is not true, scream loudly.

I'm actually concerned about inheritance of the various semaphores, mutexes,
locks and shm's.  I'm sure I can count on Bjoern to let us know if we still have
work to do in those 'other departments'.

Oh, this patch has one flaw, and I'm hoping someone suggests an easy solve.
I do bother testing the APR_FILES_AS_SOCKETS to avoid trying to toggle
a value which would be quite invalid.  However, that's only partially effective
since we use the same implement logic.

Perhaps we should we always provide both APR_IMPLEMENT_INHERIT_UNSET
and an alternate APR_IMPLEMENT_INHERIT_UNSET_CLOEXEC, and leave the
decision to use the _CLOEXEC flavor to open.c and sockets.c to decide?


View raw message