in reply to Making Timeout for Yourself

This is not meant to be a criticism of your code, as I really haven't looked at it much. If it works, and you understand it, then you should probably stick with it. If I were to do this, though, I think I would go with an alarm for the timeout. This is recommended by perldoc -q timeout, and is quite simple to use. Here's an example from perldoc -f alarm: 

eval {
    local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
    alarm $timeout;
    $nread = sysread SOCKET, $buffer, $size;
    alarm 0;
};
if ($@) {
    die unless $@ eq "alarm\n";   # propagate unexpected errors
    # timed out
}
else {
    # didn't
}

[download]

Replies are listed 'Best First'.
Re: Re: Making Timeout for Yourself
by pg (Canon) on Dec 31, 2003 at 21:17 UTC

    I usually try to avoid things that are not cross-platform, unless there is no other alternative. (I am definitely not saying that you are wrong.)

    alarm() is not implemented on win32, and this is true up to 5.8.2.

    The best solution is to use various socket timeouts that socket supports, not to implement by oneself.

[reply]

      Indeed, I should have mentioned that alarm doesn't work on Windows. This is brought up in the perlfaq that I mentioned, and I thought about mentioning it, but for some reason never did.

      As for your comment about avoiding things "that are not cross-platform," I agree and disagree. In this case, using socket options to set a timeout is clearly the better option. I think so not just because it's cross-platform, but also because it's a mechanism already there. I see writing one's own timeout when a builtin timeout is supplied is reinventing the wheel.

      I think we should be careful about being cross-platform to a fault, though. If one was trying to make a timeout for a system call that didn't have its own way of doing so, I would recommend using alarm. Always aiming for complete portability is, in my mind, somewhat akin to premature optimization. If something can be written much cleaner, simpler, and better with an unportable method, then I wouldn't immediately frown on it. Just as in the case of optimizing things before an actual performance problem is encountered, I think it's bad to make things highly portable before the need to do so is encountered.

      That's not to say I wouldn't choose the portable method with all other things being equal, but portability often requires a bit of hoop-jumping that can be a problem. Just like most decisions of this nature, there is a balance that needs to be considered. Making a statement that you "try to avoid things that are not cross-platform" is a generalization that gets bandied about a lot, and while it is a noble goal, isn't always practical.

[reply]
[d/l]
Re: Re: Making Timeout for Yourself
by mcogan1966 (Monk) on Dec 31, 2003 at 20:47 UTC
    I understand what what you are saying. And alarm is nice, in that way. In fact, that's what I started with. And I found out that using alarm took longer to process and more CPU usage to accomplish the same task. My whole purpose for doing this was to reduce the amound of CPU usage and processing time. The code as it is now already has enough forking and such to clog up the CPU.

    Just because that's the way it's been done before doesn't mean that the way we should keep doing it.

[reply]

In Section Meditations