develooper Front page | perl.perl5.porters | Postings from October 2001

Re: [PATCH perl@12696] C RTL awareness update for VMS

Thread Previous | Thread Next
October 29, 2001 09:27
Re: [PATCH perl@12696] C RTL awareness update for VMS
Message ID:
Jarkko Hietaniemi <> wrote:
> On Mon, Oct 29, 2001 at 10:11:46AM -0500, Tom Edelson wrote:
>> I can readily believe that many folk would expect them to be persistent.  On the other hand, those of us who were steeped in VMS long before we came to Perl might expect the contrary.
>> The only conclusion I wish to draw is that whatever is chosen will go against someone's expectations, and therefore, will need to be documented quite explicitly.

> Where should this be documented?  That is, where would you expect
> this to be documented?

It's implied on the Perlipc page that signal handlers might not
persist.  But it's in terms of BSD vs.  SysV, which doesn't mean a lot
to us non-Unix types.

If we can fix non-persistent -> persistent, there should be no backwards
compatibility problems, really:

OLD:    alarm#1-> handled   alarm#2->error exit with stack dump
NEW:    alarm#1-> handled   alarm#2->handled

Somehow I doubt that anyone is using the old "stack dump" behavior.

And no, I don't want to remove persistancy for anyone that is fortunate
enough to have it!

>> I think modern signal behaviour says that signal handlers stay in
>> effect until cleared by sigaction() SA_RESETHAND or exec*().

Well, I took a look at the signal() manpage on a Linux system
and it says you can get either behavior depending on whether you
include <signal.h> or <bsd/signal.h>

Standards, I love 'em...there are so many to choose from!

What I was hoping was a feeling for "this is SO broken it should be
fixed" vs. "this is within the range of normal behavior".   Sounds
like the answer is: BOTH.

More recent VMS systems have a working sigaction() and can get
persistent handlers; older ones just have system().  All the signals
are handled via Perl_csighandler, so I wonder if we can add some code
to automatically re-set signal() on those systems that need it.
 Drexel University       \V                    --Chuck Lane
     (215) 895-1545     _/ \  Particle Physics
FAX: (215) 895-5934     /\ /~~~~~~~~~~~

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About