nested alarm signals (fwd)
John R. Comeau
comeaujr at sd.conexant.com
Thu Jun 15 17:11:52 CDT 2000
Carl> There are a large number of system calls that are unsafe to
Carl> make while inside a signal handler. Any attempt to call
Carl> these may result in incorrect, undefined, or otherwise
Carl> disastrous behavior. I was looking for a complete list, but
Carl> failed to find one. However, I'm certain that among them
Carl> are: fork, exec, read, and write.
Carl> That means no spawning other processes, and no file or
Carl> terminal I/O while in a signal handler. Frankly, I'm amazed
This is really bad news for me. I have a pretty large application
that's based on forking child processes from an alarm signal handler.
It's working pretty well except for this issue of generating another
Given that my example is able to spawn the new process, I wonder what
it is about that spawned process that indicates that it can't respond
to (or set?) its own alarm. That is, is there some way that one can
look at the output of 'ps' to see that this spawned process is running
in some kind of special state (e.g. it's running from a signal
If one can't fork the child processes in a signal handler, how does
one write a multi-threaded application? My approach was that I would
spawn these child processes from the alarm signal handler so that they
would be started even if the program was waiting for user input from
STDIN. Like I said, it seems to be working fairly well. But I don't
want to write something that won't work on a slightly different flavor
of Unix or that might not work when the OS is in some slightly
I guess that I should spawn a single child process (outside of an
signal handler) and then communicate with that child periodically.
How is the idle callback handled in pTk? Wouldn't that be some kind
of alarm? If so, do the same restrictions apply?
John Comeau (john.comeau at conexant.com) 858-713-3593 (W)
Ihr neuer Verehrer liest ihr jeden Wunsch von den
Her new admirer anticipates her every wish.
The posting address is: san-diego-pm-list at hfb.pm.org
List requests should be sent to: majordomo at hfb.pm.org
If you ever want to remove yourself from this mailing list,
you can send mail to <majordomo at happyfunball.pm.org> with the following
command in the body of your email message:
If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-san-diego-pm-list at happyfunball.pm.org> .
This is the general rule for most mailing lists when you need
to contact a human.
More information about the San-Diego-pm