apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ingo Weinhold <bonef...@cs.tu-berlin.de>
Subject UNIX apr_procattr_child_{in,out,err}_set()
Date Thu, 02 Dec 2004 14:36:16 GMT
Howdy,

I just came across the apr_procattr_child_{in,out,err}_set() 
implementations for UNIX and got to wonder about the semantics of those 
functions. Their doxygen comments are lacking a bit of preciseness.

What I understand is, that by using apr_procattr_io_set() it is defined, 
which of stdin/stdout/stderr the child process inherits from its parents 
and for which pipes are created. I also see what 
apr_procattr_child_{in,out,err}_set() shall do, if I pass a pipe. But in 
case one or both of the supplied file handles are NULL, the implementation 
behaves a bit strange, IMHO.

If I want to direct my child process' stdout to a log file I have already 
open, I would intuitively pass the pair (<log file>, NULL) to 
apr_procattr_child_out_set(). What the implementation does in this case, is 
to create a pipe and then replace the child part with my log file, but keep 
the parent part.

Even stranger I find the behavior in case of passing a (NULL, NULL) pair. I 
would expect the inheritence behavior from the parent process to be 
restored, but instead a pipe is installed.

Personally I would consider it straight forward, if the functions would 
always close the file handles that are there and set them to NULL and then 
dup() the non-NULL arguments. A (NULL, non-NULL) argument pair doesn't seem 
to make much sense, so it could be considered an error case.

Does that sound reasonable or do I miss something?

CU, Ingo

Mime
View raw message