>>>>> "ML" == Marc Lehmann <[EMAIL PROTECTED]> writes:
ML> Its a design decision. Combining timers with io watchers is unnatural, ML> because: ML> - you often don't need both, so shouldn't be forced to pay for them ML> - you can't choose the type of timeout (event only has absolute timers ML> anyways, though, which are unsuitable for many tasks such as idle timeouts ML> for i/o, where you need relative timeouts). ML> - you have to manage two timeouts or weirder stuff when you have ML> two separate i/o watchers, or use a third watcher (paying even more). ML> - it is often unclear on which events exactly the timeout gets reset ML> (if at all), and even if not, there is no flexibility (how do you ML> chose between an idle timeout and an overall timeout ML> for completion with Event? you cannot). ML> As it is trivial to create a separate timeout (and much faster than with ML> Event, too), there is no drawback to this design. i do that in stem's event layer too. i/o watchers are created and an optional timer is added if desired (a separate event with a different method to callback into the object). this means all the event layer needs is simple i/o watchers and a simple timer. my code builds up the combined i/o with timer as needed. much cleaner and easier to manage at all levels. as marc said it is also simpler in the lower levels to code up. and i bet most i/o watchers don't need timers which saves on the storage and coding. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
