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.
In particular notice this text:
If your system has the sigaction() function then signal han-
dlers are installed using it. This means you get reliable sig-
nal handling. If your system has the SA_RESTART flag it is
used when signals handlers are installed. This means that sys-
tem calls for which restarting is supported continue rather
than returning when a signal arrives. If you want your system
calls to be interrupted by signal delivery then do something
like this:
use POSIX ':signal_h';
my $alarm = 0;
sigaction SIGALRM, new POSIX::SigAction sub { $alarm = 1 }
or die "Error setting SIGALRM handler: $!\n";
See POSIX.
While this text is also in the perl 5.6.1 perlvar man page, I think that
perl 5.6.0 does not infact use SA_RESTART (or at least for some reason
our build of it did not). Running truss -v all on Solaris 5.8 (sun4u
hardware), reveals that our perl 5.6 does not pass SA_RESTART to the
sigaction routine, and perl 5.8.x does.
The problem we had was that we were using alarm() to kick us out of the
DBI->connect() using DBD-Oracle when connecting (to a database on a
machine that is down). Perl 5.6 it works, and in perl 5.8 it just
causes the connect to restart. At first we thought this was an oracle
9.2 vs 8.1.7 issue because we had built our 5.8 tree against oraclce
9.2.
Retesting with code like that quoted above caused us to get the old
behavior.
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()
} );
};
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.
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.
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
> > ----------------------------------------------------------------
> >
