On Sat, Jan 10, 2004 at 02:47:41AM -0500, Lincoln A. Baxter wrote:
> Tim and Steve,
>
> I think this is the same problem I was having before, which I thought
> at the time was an Oracle 9i issue. I stopped working on it for about 9
> months, put I must get us to perl 5.8 for the unicode support, so I was
> looking at it today, and I think we just figured it out (with the help
> of truss).
>
> Read:
>
> perldoc perlvar #search for ALRM.
Also relevant in this area is this from perl581delta.pod and the docs
it references:
=head2 Unsafe signals again available
In Perl 5.8.0 the so-called "safe signals" were introduced. This
means that Perl no longer handles signals immediately but instead
"between opcodes", when it is safe to do so. The earlier immediate
handling easily could corrupt the internal state of Perl, resulting
in mysterious crashes.
However, the new safer model has its problems too. Because now an
opcode, a basic unit of Perl execution, is never interrupted but
instead let to run to completion, certain operations that can take a
long time now really do take a long time. For example, certain
network operations have their own blocking and timeout mechanisms, and
being able to interrupt them immediately would be nice.
Therefore perl 5.8.1 introduces a "backdoor" to restore the pre-5.8.0
(pre-5.7.3, really) signal behaviour. Just set the environment variable
PERL_SIGNALS to C<unsafe>, and the old immediate (and unsafe)
signal handling behaviour returns. See L<perlrun/PERL_SIGNALS>
and L<perlipc/"Deferred Signals (Safe Signals)">.
In completely unrelated news, you can now use safe signals with
POSIX::SigAction. See L<POSIX/POSIX::SigAction>.
=cut
> The problem I am now trying to work out is, how to get the equivalent
> of the following using sigaction:
>
> my $alarm = 0;
> eval {
> local $SIG{ALRM} = sub { $alarm=1 };
> alarm(3);
> $dbh = DBI->connect( "dbi:Oracle:$dbn", $usr, $pwd
> ,{ AutoCommit=>$self->auto_commit()
> ,RaiseError=>1
> ,PrintError=>$self->print_err()
> } );
[You ought to alarm(0) inside the eval block as well, else there's
a chance the alarm will be delivered between the eval and ending
and the following alarm(0). That would be fatal.]
> };
> alarm(0);
> if ($@)....
> if ( $alarm ).... etc
>
> Notice that in this code, the fact the $SIG is declared local inside the
> eval block, causes the original signal handler is restored when the eval
> block exits.
>
> I suspect that the only way to get this behavior is to use sigaction,
> BOTH in the eval, and after it to reset the orginal handler. Problem is
> it seems to break things kind of badly when I do. Perhaps declaring
> local ${ALRM} = undef; FIRST inside the eval will do it.
Possibly. I think you'll find perl5-porters helpful here in tracking
what the guts are doing.
> I will share the solution when I have it figured out. In fact, would be
> willing to give you a README.signals file to include in DBI docs if I
> get it figured out.
If you figure it all out I'll not only add your write up to the
DBI.pm pod, I'll use it as the basis for the relevant part of the
2nd edition of the DBI book :-) Your name will be in lights!
Tim.
> Lincoln
>
>
> On Fri, 2004-01-09 at 18:44, Tim Bunce wrote:
> > I'm not familiar with all the details. Best to ask perl5-porters.
> > (Remember to append your perl -V output)
> >
> > Tim.
> >
> > On Fri, Jan 09, 2004 at 05:06:46PM -0500, Steven N. Hirsch wrote:
> > > Tim,
> > >
> > > I've run into an odd problem using the DBI::Proxy. In Programming Perl -
> > > 3rd Edition, the claim is made that Perl will always try to restart
> > > interrupted "slow" system calls if POSIX sigaction() is supported.
> > >
> > > Our experiences are suggesting that this is not correct. We have an
> > > application which connects over the Proxy and forks children (which also
> > > establish their own connections - this is another can-of-worms for future
> > > discussion). Unfortunately, the PlClient dies (with EINTR) if the DBI
> > > is in read() or write() at the time a child terminates. I can see
> > > clearly that the code (Comm.pm) is not trying to handle this case,
> > > believing (as I did) the claim of Perl doing the "right thing" and
> > > restarting the call.
> > >
> > > Before I tear into it, I want to make sure I have come to the correct
> > > conclusion. Certainly, perl-5.8.0 is not using SA_RESTART anymore, but
> > > there is other "magic" going on in support of "safe interrupts" which I do
> > > not fully understand.
> > >
> > > What is your take on this?
> > >
> > > Regards,
> > >
> > > Steve
> > >
> > > --
> > > ----------------------------------------------------------------
> > > Steven N. Hirsch tie-line: 446-6557 ext: 802-769-6557
> > >
> > > Staff Engineer Methodology Integration Team
> > > ASIC Product Development IBM Microelectronics
> > > ----------------------------------------------------------------
> > >
>
