apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject challenges creating processes from threaded environment?
Date Sat, 24 May 2003 01:02:26 GMT
consider code that does something like the following:

apr_procattr_io_set()
/* we now have 6 pipe handles with no cleanup-for-exec on any */
apr_proc_create()
/* parent now has 3 of the pipe handles with no cleanup-for-exec on any */
apr_pool_cleanup_register(parent handle to child's stdin,
                           child cleanup to close file)
/* now we know that other processes created between now and when we're 
through writing to child's stdin won't inherit the handle too and 
prevent the child from seeing EOF when this thread closes it */

But this entire sequence needs to be in a critical section because any 
other code in the process doing an apr_proc_create() at about the same 
time can inherit this child's handles and cause problems.

I encountered this problem in Apache's mod_ext_filter, which spawns a 
child process to filter a response from the server.  Banging on the 
server and having it spawn sed to filter the response left a number of 
sed processes hanging around, all waiting for EOF on stdin.  But each 
sed's stdin pipe was led open by another sed process, so it mattered not 
that Apache had closed its side of the pipe since the pipe was still open.

For mod_ext_filter I can hold a thread mutex around the critical section 
  above, and that protects it from other instances of mod_ext_filter 
doing fork() and inheriting the wrong handle, but it does nothing for 
other threads calling apr_proc_create().

It would seem that all of the pipe creation and child cleanup 
registration needs to be done inside apr_proc_create() so that it can 
hold a mutex and all callers of apr_proc_create() will be happy.  I 
didn't look at it to know if that would require API changes.  I wouldn't 
be shocked.

Thoughts?



Mime
View raw message