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: apr_proc_create {detached} pipes?
Date Mon, 16 Apr 2012 20:03:59 GMT
On 4/12/2012 10:37 PM, William A. Rowe Jr. wrote:
> Has anyone else ever encountered an opportunity to detach a process,
> which you would still enjoy stdio channels to communicate?
> 
> First I actually have bumped into this, but we didn't seem to leave
> much in the way of an apr_proc_detach that avoids shuttering stdio
> handles that were *just configured* through the procattr.  Seems
> sort of strange to me, because the docs don't make this clear.
> 
> Wondering if there is room for improvement here or am I hitting a
> rare edge case?

Let's just say that the procattr_create reserved /dev/null tags for
the behavior, and that the proc_create did not actually call the
"close my handles" flavor of apr_proc_detach, but called the subset
(or used a new, unique and internal flag to tell apr_proc_detach
not to close handles).

What do people believe or dev rules dictate?  Is this a 'bug' that
can be fixed in 1.4.x?  Does it require 1.5.0 although there is no
binary ABI change?  Does this require 2.0.0 due to the behavior
change?  I'm tempted to suggest that it can be fixed in 1.4.x since
the behavior today makes no sense.

In the proposed bug-fix, any call to the several procattr io calls
would unset the /dev/null behavior.  Also, any call to the several
procattr io calls would ensure any handles were cleaned up, per the
bug report Stefan noted.

I can work up the patch but am wondering what needs to happen for
the committers to agree on a 1.4.x or 1.5 acceptable change.


Mime
View raw message