On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
We agree. APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual
case) value.
my complaint is that you're modifying all the handle creation APIs with
another parameter...
-dean
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn, rather
assuming
that the inherit flag is _not_ set, and force the user to call
apr_socket_inherit_set
or apr_file_inherit_set.
Does this work for
+1 from me too (although i don't know that i necessarily have a vote in
APR :)
-dean
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn,
rather assuming
.
- Original Message -
From: William A. Rowe, Jr. [EMAIL PROTECTED]
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
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.
