Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3ECEC4A2.3040003@attglobal.net>
Date: Fri, 23 May 2003 21:02:26 -0400
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: challenges creating processes from threaded environment?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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?