Re: maint-5.8@34289 on VMS

On Sep 6, 2008, at 8:42 PM, Fred Morris wrote:

> As I recall the FORCEX system service also takes an optional status  
> code to be
> used by the exiting subprocess... don't know if that helps or not.
>
> On Saturday 06 September 2008 15:33, Hein van den Heuvel wrote:
>> You may want to check out SYS$FORCEX
>> That would kill an (perl) image but leave DCL (command file) running.
>>

Fred and Hein,

Thanks for the comments.  ;-) encouraged generally not is posting top  
lists Perl the On.

What we're talking about here is code written in Perl that monitors  
either another thread or another process running a test script and  
stops it if it gets stuck so that the rest of the test suite can  
continue running.  Perl code does not have direct access to SYS$FORCEX  
(though it is using kill(), which is implemented via SYS$SIGPRC, which  
is essentially the same thing as SYS$FORCEX except with the ability to  
affect other processes).  John has explained rather well why there is  
an unexpected side effect on VMS:

>> On Sat, Sep 6, 2008 at 5:58 PM, John E. Malmberg <[email protected]>  
>> wrote:
>>>
>>> On Unix the perl program runs with its own process ID.  With VMS,  
>>> the perl
>>> program runs in the process ID of the shell.
>>>
>>> So it is the shell that is being killed instead of the Perl program.

Right.  Running a program does not normally start a new process on  
VMS, though the Perl test suite *does* normally start a new process  
for each test script.

>>> We need to have a method of killing the Perl process with out  
>>> killing the
>>> shell on VMS.
>>


We have that method.  It's called exit().  I think if we just call  
exit() instead of kill() in the threads case, that will do away with  
unexpectedly losing the outermost process.

But this is all downstream of the immediate problem, which is that in  
the watchdog() function in t/test.pl, the C<sleep(120)> call returns  
in one second, not 120, and I've verified in the debugger that  
Perl_pp_sleep in pp_sys.c does actually get an integer value of 1 and  
passes it along to the sleep() in the C run-time.  I have not (yet)  
been able to reproduce that outside the context of ext/threads/t/ 
free.t -- sleep() usually works just fine.

________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser