On Jan 31, 8:55am, Joshua N Pritikin wrote: > On Sun, Jan 27, 2002 at 09:43:20PM -0500, Allen Smith wrote: > > In other words, if one has one_event(0), will this mean that any > > poll/select call will have a timeout of 0, > > Yes.
Ah. Good. The existing manpage is, I am afraid, confusing on this point, when it says "If there are no events available, block forever or until $timeout" - this implies this is only used when there are no possible events, which isn't the case. > > P.S. It would actually be nice if timeout_cb could be invoked with > > a worse priority than the main cb was invoked at, BTW. > > Really? Why do you need so much control? Pretty frequently, timeouts are a somewhat arbitrary choice, as all the arguing about proper configuration of them in TCP et al shows. Often, timing out "right on the dot" is not all that important, or at least is not as important as a lot of other things that the program could be doing. It also allows for the possibility that the timeout is set too low (as is one reason for timing out - see http://www-nrg.ee.lbl.gov/papers/congavoid.pdf page 7, for instance), if the timeout is queued as a seperate event which can be preceded by other checks of select (thanks to going through one_event via loop), which may detect that the i/o watcher should be triggered after all. > Is it really more than a theoretical improvement in symatics? It's admittedly doable via a seperate timer watcher which cancels the i/o watcher (and vice/versa), and a constructor for both of these is not too hard to build (unless there's some odd interaction between Event and perl closure for callbacks that I haven't come across yet). -Allen -- Allen Smith [EMAIL PROTECTED] September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
