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 Wed, 18 Jul 2001 00:47:15 GMT
From: "dean gaudet" <dean@arctic.org>
Sent: Tuesday, July 17, 2001 7:14 PM

> On Fri, 13 Jul 2001, William A. Rowe, Jr. wrote:
> > 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;
> this sounds like the wrong approach.
> the default should be to assume that all file handles are not inherited.
> this is the 99% case for handle creation.

We agree.  APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual case) value.

> then as a "new process attribute" you list the handles which should be
> inherited.  (in general these would be just the 3 standard ones.)

Hmmm... I'm thinking of cooking up _something_ along those lines, esp for Win32.

> it's possible to write a linux clone()-based fork() which inherits nothing
> by default without having to do lame-ass stuff such as setting O_CLOEXEC
> on every bloody handle.  then you just open("/proc/parent/fd/n") to get
> the handful of descriptors you wanted to inherit (or use other fd passing
> methods).  this should be a faster fork() off a large multithreaded, lots
> of fds server.

AHHH... didn't pay attention that you were going to play with a custom tweak here.
Since it isn't cross-platform though, I believe the code now committed still makes
sense, and should be overriden by platform in arch/someplat/inherit.h or the
some_api/some_plat/apicode.c module.  I'm just noticing the rather redundant checks
could be cleaned up with another macro in inherit.h to further introduce some
consistency here.

> and it's even simpler on windows... your API would seem to be worse for
> windows than it needs to be.

Actually, the APR_INHERIT is implemented on Win32, as an inheritable HANDLE, but
that's about it.  It will certainly need to become a little more sophisticated.

Sort of comes back to needing a fork() on Win32, for certain cases :)  For create
process, we need some mechansim to pass up all the 'other' things we offered to
inherit, and for those I don't have a good answer at this moment.


View raw message