Re: [boost] Re: Child processes

From: John Fuller (jfuller_at_[hidden])
Date: 2004-06-23 09:24:16

Just some memories about UNIX child processes here

- On UNIX systems where I have a daemon fork children, often
I build into its service loop a nonblocking wait for any suspended 
children.
(NOHANG).  I agree it's good to get the return status of the children.

- As a last resort, I suppose one could ioctl the file in the proc 
directory
for a process.

- Using SIGCHLD can be tricky if some children are forked by third 
party code:
for example a database client "shadow process" may have its own 
handling,
may change its own process group, and/or on termination may have an 
unexpected
effect on the parent.  Additionally modifying the priority of children 
can have
unexpected results in these cases as well.

- I recall that signal handling in general requires a lot of care due 
to the
asynchronous nature of signals.

- I recall that process and group permissions are a tricky area, some 
capabilities
require sudo authority and some children are better off running as 
different users,
but the other side of the problem is preventing malicious use of the 
capabilities.

On Jun 23, 2004, at 3:56 AM, Angus Leeming wrote:

> Gregory Colvin wrote:
>>> namespace {
>>>
>>> std::map<pid_t, int> completed_children;
>>>
>>> int status;
>>> sig_atomic_t pid;
>>>
>>> }
>>>
>>> extern "C"
>>> void child_handler(int)
>>> {
>>>         pid = wait(&status);
>>>         std::map<pid_t, int>::iterator it =
>>> completed_children.find(pid);
>>>         if (it != completed_children.end())
>>>                 it->second = status;
>>> }
>>>
>>> I'm pretty sure that the above is safe code.
>>
>> It's unsafe because it's not reentrant.
>
> Really? I thought that Posix guaranteed that a handler receiving only 
> one
> type of signal (SIGCHLD in this case) would not receive multiple
> calls simultaneaously? Is this not true in the presence of threads?
>
>> But why do you need to reap the zombie?  I've implemented
>> the java process control natives with no need for reaping.
>
> Addressed elsewhere.
>
> Angus
>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>