> As it is trivial to create a separate timeout (and much faster than with
> Event, too), there is no drawback to this design.
As it might not be too obvious, here is (in pseudocode) an example
of an idle timeout, i.e. a timeout that triggers afetr some time of
inactivity. It uses two watchers (which is not required but customary):
# 60 seconds idle timeout
my $to = EV::timer_ns 0, 60, sub {
close $fh; ... log error;
};
$fh = ... new socket;
$to->again;
my $wr = EV::io $fh, EV::READ, sub {
$to->again; # reset timer
# do stuff
};
my $ww = EV::io $fh, EV::WRITE, sub {
$to->again; # reset timer
# do stuff
};
The read and write watchers can easily be started and stopped
independently of each other this way, and also independent of the timeout
($to->stop ... $to->again is a valid sequence to temporarily disable a
timeout, e.g. when the connection is not dpoing any work and can be kept
open).
If you try to do this in event and re-use one watcher's timeout, you will
need to stop/start it each time you get activity, which is rather costly
(and costs a lot when one uses e.g. the epoll backend). Of course one can
use a separate watcher with Event, too.
If an overall timeout is required (e.g. a single request must be done
afetr 90 seconds, no matter what), the code becomes simpler (basiclaly its
then using a simple timer and never resets it):
# 90 seconds idle timeout
$fh = ... new socket;
my $to = EV::timer_ns 90, 0, sub {
close $fh; ... log error;
};
my $wr = EV::io $fh, EV::READ, sub {
# do stuff
};
my $ww = EV::io $fh, EV::WRITE, sub {
# do stuff
};
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
