Boost logo

Boost :

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
(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
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
may change its own process group, and/or on termination may have an
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
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

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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at