nested alarm signals (fwd)

Bobby Kleemann rkleeman at
Thu Jun 15 17:39:26 CDT 2000

On Thu, 15 Jun 2000, John R. Comeau wrote:

> If one can't fork the child processes in a signal handler, how does
> one write a multi-threaded application?

A slight confusion here I should clear up:  multi-threaded means that
several "processes" are running in the same global memory space, but at
different times.  If you really want a threaded perl app, you should build
perl with threads and use that interface.  WHat you are doing here is a
multi-process app that (I think) is trying to use signals as an IPC
mechanism, which can be done better with pipes or shared memory.

>  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

Why not spawn helper programs before you look for input?  Or why not just
set a flag in the sig handler and in whatever loop you have around the
STDIN loop launch your alternate process.

use vars qw($ALARM_SIGNALED);

while (<STDIN>) {
	... Continue processing STDIN.

Careful with this one though, because I'm not sure how the read of STDIN
will react to being interrupted (you may loose your data on certain

>  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.

Yes, definitely spawn outside the signal handler.

> How is the idle callback handled in pTk?  Wouldn't that be some kind
> of alarm?  If so, do the same restrictions apply?

Hopefully someone with pTk knowledge will know.

 _ _ _
 Bobby Kleemann <rkleeman at>


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