nested alarm signals (fwd)

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


~sdpm~
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
> STDIN.

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);
$SIG{ALRM} = sub { $ALARM_SIGNALED++ }

while (<STDIN>) {
	if ($ALARM_SIGNALED) {
		$ALARM_SIGNALED = 0;
		launch_other_proc();
	}
	... 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
systems).

>  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 neta.com>
 http://www.neta.com/~rkleeman/

~sdpm~

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:

    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 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 mailing list