nested alarm signals (fwd)

John R. Comeau comeaujr at
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
different state.

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 858-713-3593 (W)
Ihr neuer Verehrer liest ihr jeden Wunsch von den
Augen ab.

Her new admirer anticipates her every wish.

The posting address is: san-diego-pm-list at

List requests should be sent to: majordomo at

If you ever want to remove yourself from this mailing list,
you can send mail to <majordomo at> with the following
command in the body of your email message:

    unsubscribe san-diego-pm-list

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> .
This is the general rule for most mailing lists when you need
to contact a human.

More information about the San-Diego-pm mailing list