19 Apr
2010
19 Apr
'10
1:02 p.m.
2010/4/19 marius zbihlei <marius.zbihlei(a)1and1.ro>ro>:
Indeed, main process is the process after the fork,
and this is the
process that writes to signal the parent. I see two possible pitfalls:
1. If the main process blocks, this will block the
parent process also
This could be improved using select() with a timeout, right?
2. If the main process returns without writing the
bytes, and there are
still child processes left(tcp or udp worker children etc), then they will still
have the writing part of the socket open (forked from the main process)and again
the parent (master) process will keep blocking (didn't discovered a case where it
might happen).
Then the workers should immediately close the pipe output fd after
being created, right?
With a select it is possible to do a blocking read
from some time. I
strongly suggest more than 4-5 seconds, I think 30s should be a minimum.
ok, but IMHO 30 seconds is too much for a init script. However this is
a corner case.
> Anyhow, I wonder if it would be enough. Note that
in case the main
> process gets blocked and the parent process exits with -1 (due to the
> suggested timeout) the main process still remains running (even if
> blocked). Perhaps the parent process should kill it and ensure it's
> dead in case such timeout occurs?
Good question.. We can kill all children from the main
proces, but I am not
sure that from the masetr process we can do this..
But if we just kill the main process from the parent process, then all
the workers and rest of children would be killed, right?
The problem would be if the main process gets "blocked" for some
reason, but I think that is a terrible case I've never seen.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>