Hi all,
Many of us have, at one time or another, probably noticed that:
1. If one tries to connect to a database on a box which is down... one
hangs for about 4-8 minutes. This is a SQL net/TCPIP problem and is
documented on the OTN network.
2. It is possible for a statement execution to hang on a locked
resource in the database.
Now, lets assume that we are trying to write code that is willing to give
up, if something is going to take more than a few seconds, but would like if
possible to do so gracefully. We are willing give up ungracefully if we
can't be graceful because we want to free the resources to do something
else.
The temptation is to try to introduce graceful timeout behavior with code
that generally looks like this:
local $SIG{ALRM} = sub { die ; };
alarm( 5 );
eval { do_the_db_work(); };
alarm( 0 );
handle_die if $@;
For a variety of reasons, (see the links cited below), this could interrupt
things in a way that might cause a segfault, and crash.
http:[EMAIL PROTECTED]/msg87982.html
<http:[EMAIL PROTECTED]/msg87982.html>
http:[EMAIL PROTECTED]/msg14835.html
<http:[EMAIL PROTECTED]/msg14835.html>
Now let us assume that we are willing to live with the possibility that a
program could segfault and crash, if this occurs, because our alternative is
to kill the job with an external kill if it does not finish what it is doing
quickly. Basically we are willing to live with the somewhat flaky behavior
we might get. (Thats life with perl and signals) (see the perldoc pages).
Here are two questions which we would like to introduce for discussion:
1. Could the mere presence of the $SIG{ALRM} handler and
Time::HiRes::ualarm calls cause problems, even if the alarm doesn't fire?
2. Could interrupting library code cause the program to be left in an
executing (non-terminating) but _debilitated_ state which we could not
detect?
Thoughts anyone?
Lincoln
