OK, here's a teaser:
I have a multi threaded program. Each thread can do a fork and
exec. The return value of the fork (the child pid) is stored in
a global table (the applicable entry of which has been 'allocated'
under protection of a mutex and is, therefore, safe for the thread
to use).
There is a signal handler for SIGCHLD. There pretty much HAS to be
because my multi thread program is a language environment and the
fork/execs are implementing asynchronous 'interested in the
return value' and 'not interested in the return value' external program
call facilities for the language user. Although I could handle all
the 'interested' calls with a wait when the user performed a 'get
return value' operation, he will never do so for an 'un-interested'
call and I must clear up zombies.
Note - GNU advise us NOT to use mutex actions in signal handlers
due to dealock possibilities, and I can't use POSIX semaphores due
to the fact that HP-UX and AIX do not support them (in the
versions we develop for) and this code must work on all three.
However, I think I have most of the issues covered with proper use
of atomic actions etc.
But one issue I cannot be sure of:
Does 'fork' garauntee to return the pid to
the parent process before the child process is executed
and its SIGCHLD termination signal is handled! If not, then
the signal handler can never be sure that the child for which
it has status has been fully added to the 'child table' and,
therefore, there is a minor possibility of 'losing' the signal
(i.e. the handler can't find the entry so it forgets it).
Sticky eh?
Prompt advise is sought.
Thanks
===========================================================
_/ _/_/_/_/
_/_/ _/_/ _/
_/ _/_/ _/_/_/_/ Martin John Bartlett
_/ _/ _/ _/ ([EMAIL PROTECTED])
_/ _/_/_/_/
_/
_/ _/
_/_/
===========================================================
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
