Kelly,
What I suspect is happening is that you are terminating the client
process/thread, whatever to receive the data from the query. The backend sql
process does not know that the client no longer wants the results from the
query so it continues along till it needs to talk to the client. Then when
it does that's where the trouble starts. You should be able to test this
theory. I can't remember what database you are using but run your script
and when it time-outs a query use your DB's montitoring tool and see
it that query is still running on the backend. If it is I believe that is your
problem. In my opinion it generally is not a good idea to kill the client and
not wait till the backend acknowledges the kill. I believe Informix used to
have a environment variable you could set that would allow to interrupt
long running SQL statements. If Jonathan Leffler reads this he could tell
us what it is.
-Paul
>
>
> Tim,
>
> This is exactly the example that I used. I can get the program to run for
> a few iterations, and handle a few timeouts, but it eventually seg
> faults. :(
>
> I'm including the output generated from print statements in my script. It
> shows a few iterations, a few timeouts, then a seg fault. I can get the
> signal to work, but the seg fault over time is what I'm concerned about.
> Any suggestions for this?
>
> > Kelly,
> >
> > I think that what you want to achieve can be done with the alarm() function.
> > If you use it in an eval block, it won't kill the program. Here's a simple
> > example (from "Perl: The Complete Reference" by Martin Brown, pg 455):
> >
> > print "Your name is? :\n";
> > eval
> > {
> > local $SIG{ALRM} = sub { die "Timeout" };
> > alarm(10);
> > $name = <STDIN>;
> > chomp $name;
> > alarm 0;
> > };
> >
> > if ($@ and $@ =~ /Timeout/) { $name = 'Anonymous' }
> > print "Hello $name!\n";
> >
> > alarm(10) sets the alarm for 10 seconds. alarm(0) turns it off. The special
> > variable $@ aka $EVAL_ERROR will be empty if the eval execute without error,
> > otherwise it holds the "die" message.
> >
> > There is also a good discussion of this stuff in the O'Reilly book
> > "Programming Perl".
> >
--
Internet: | Paul J. Falbe |
[EMAIL PROTECTED] | Cassens Transport | Std disclaimers apply.
Voice: | 145 N. Kansas Str. | (But you knew that!)
618-656-3006 | Edwardsville, IL 62025 |
