Re: Timeouts when reading from socket Filehandles?

If you want to timeout the client request, you could wrap it in an eval,

  eval {
        local $SIG{ALRM} = sub { die "Timed Out" };
        alarm 10;
        ### IO::Socket/Select function call goes here
        alarm 0;
    };
    if ($@ and $@ !~ /Timed Out/) {
        die
    }
[download]

this should give you a 10 second timeout on your function call.

--
hiseldl

Comment on Re: Timeouts when reading from socket Filehandles? Download Code

Replies are listed 'Best First'.
Re: Re: Timeouts when reading from socket Filehandles? by sporte01 (Acolyte) on Aug 27, 2002 at 17:35 UTC
It might be smarter to save the old signal value outside the eval, and restore it after the eval. Yes, setting it local works fine. I totally agree with that much. If the eval crashes on any code between your alarm 10 and alarm 0, the eval breaks. Granted, you have code to check for errors, but if people don't check, you can get some really bizzare errors on things such as cgi's with apache. I saw code that never hit the alarm 0 'cause the eval died (no, not die()) on a particular line, and bailed on the eval, causing processing to die randomly due to the alarm never being reset :)	[reply]

Replies are listed 'Best First'.

Re: Re: Timeouts when reading from socket Filehandles?
by sporte01 (Acolyte) on Aug 27, 2002 at 17:35 UTC

If the eval crashes on any code between your alarm 10 and alarm 0, the eval breaks. Granted, you have code to check for errors, but if people don't check, you can get some really bizzare errors on things such as cgi's with apache.

I saw code that never hit the alarm 0 'cause the eval died (no, not die()) on a particular line, and bailed on the eval, causing processing to die randomly due to the alarm never being reset :)

[reply]