RE: Can't handle a signal twice?

[Tom Edelson]

With those changes, in my environment, it still hangs on the second call to 
synchronize ().  

The output I would want to get is something like this:

--snip--

$ show process

21-NOV-2001 11:20:25.51   User: TOEDEL           Process ID:   2B21D8A3
                          Node: AX7000           Process name: "TOEDEL"

[stuff omitted]

$ perl foo.pl

Process ID is 723638435 (hex 2b21d8a3).

Open succeeded.

SET NOON
WRITE SYS$OUTPUT "Command 1."
Command 1.
 PERL -e "print kill (SIGALRM, 723638435)"
1
 FooBar!
WRITE SYS$OUTPUT "Command 2."
Command 2.
 PERL -e "print kill (SIGALRM, 723638435)"
1
WRITE SYS$OUTPUT "Command 3."
Command 3.
LOGOUT
  TOEDEL       job terminated at 21-NOV-2001 11:14:18.31

  Accounting information:
  Buffered I/O count:                979      Peak working set size:       5392
  Direct I/O count:                    8      Peak virtual size:         171072
  Page faults:                       293      Mounted volumes:                0
  Charged CPU time:        0 00:00:00.10      Elapsed time:       0 00:00:01.15

Close done.

--snip--

Did you get something more-or-less like that with your changed script, in your 
environment?

I can see that it could be helpful to explain what I'm attempting here.  I want to 
start a slave process: my Perl program sends DCL commands to it, and it processes 
them.  For what I want this "DCL server process" to do (which includes multiple runs 
of SAS), if I can get this working, it will be a lot easier, and a bit more efficient, 
than repeated use of system () or backticks.  

A challenge to this approach is that sometimes the Perl program needs to synchronize 
on its DCL server process, that is, to wait until the server has finished running all 
the commands fed to it so far.  My synchronize function (repeated below) attempts to 
address that as follows: set up a local handler for SIGALRM; then send the server 
process one more command, which tells it to send the signal back to me; then go to 
sleep and wait for the signal to arrive. 

--snip--

sub synchronize {

 eval {
  local $SIG {ALRM} = sub {die;};
  print $writeme "PERL -e \"print kill (SIGALRM, 0x$pid)\"\n";
  sleep;
 };

 sleep 1; # to let the output from the inner Perl get printed before we go on.

} # end sub synchronize 

--snip--

/ Tom Edelson

-----Original Message-----
From: Craig A. Berry [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 20, 2001 4:43 PM
To: Tom Edelson
Cc: [EMAIL PROTECTED]
Subject: Re: Can't handle a signal twice?


At 11:40 AM 11/20/2001 -0500, Tom Edelson wrote:
>I'd love to find out that this is pilot error (sorceror's apprentice error?), but I 
>fear not.  It looks for all the world like, in certain circumstances, even if you 
>attempt explicitly to re-establish a signal handler that's been used, it won't work a 
>second time.  


I'm not sure I fully understand what you are trying to do, but the following 
change appears to make it work.  You have to import the POSIX constants if 
you want to use them, and the signal name is SIGALRM, not ALRM, though 
rather confusingly I think you are right that the key in %SIG is ALRM.

--- foo.pl;-0  Tue Nov 20 15:26:19 2001
+++ foo.pl     Tue Nov 20 15:32:01 2001
@@ -1,7 +1,8 @@
 use strict;
 use constant NL => "\n";
+use POSIX qw(:signal_h);
 
-my $pid = $ENV {'HOLD_PID'};
+my $pid = $$;
 
 print "Process ID is '$pid'.\n\n";
 
@@ -30,7 +31,7 @@
 
  eval {
   local $SIG {ALRM} = sub {die;};
-  print $writeme "PERL -e \"print kill (ALRM, 0x$pid)\"\n";
+  print $writeme "PERL -e \"print kill (SIGALRM, $pid)\"\n";
   sleep;
  };