>>>>> "Z" == Zefram <[EMAIL PROTECTED]> writes:
Z> I've already got some thoughts about a better design. I think the Z> best way to approach that is first to document exactly what Z> interface Event has, as I've suggested. That would make it easier Z> to see which bits are awkward. (Example: the complicated Z> interaction of "at", "after", "interval", and "repeat" options in Z> creating timers. I'd make them more independent, to make them less Z> likely to cause surprise.) i have been doing event loop design for over 20 years and i agree the api for event could be much better. i have abstracted much of it to a higher level in stem and also it now supports wrapping different event loops. it has a pure perl one and it will one day wrap tk/gtk/etc. this is all in stem .11 which is in beta so ask me if you want a snapshot. i have been using just the event, socket and async i/o layers in a scaffold i created to drive middle layers with sessions. this is for a talk at oscon. the api for those layers is so high level, that a multi-session client is only 5 short subs and a multi listening server with multi-sessions is only 4 short subs. this is all due to very strong work on designing the apis for those layers. i can post some example code if anyone wants it. Z> However, the Event API is quite usable, and even if a complete Z> revision is undertaken we should support users of Event. Correctly Z> implementing the existing OK API should be independent of designing Z> the new super-wonderful API. From the point of view from which I Z> came to this discussion: I want to make serious use of Event *now*, Z> not wait for a new one. i think it could use a complete redesign but then i think that is true of most modules on cpan. :) i have code for a c based generic event loop that is much simpler but it isn't integrated with perl and XS. it could be the basis for another event loop core. but i ain't gonna do that as i have no time to spare. Z> What really needs to be done with the Event API is not necessarily Z> to get the cleanest handling of async events but to make it Z> possible to handle them somehow. The API just doesn't permit these Z> events to be handled properly. If you are implacably opposed to Z> making async events invisible, then you must provide a way to Z> explicitly invoke asynccheck, so that it is possible to handle them Z> correctly in cases where race conditions can be ruled out. As an Z> Event user I'd be satisfied with that. i have followed this thread lightly but i don't understand your real need. mixing threads and events is tricky. i solved it by using a pipe (to the same proc) for syncronization and job distribution. a farm of threads did blocking reads on one side of the pipe while the other side was event watched. to send work to a thread you wrote the address of a control block (c, remember!) to the pipe and a thread read it and woke up. when done it wrote the address back and the event loop saw that and read it and did the callback in the main thread. very clean and easy. in all the years i have developed event loops, i have never seemed to need a call_one_pass or handle_special_events type of sub. i just have read/write/timer/plain events with no priority queues. simple is better in most cases. and i have run these under heavy load without problems. just my $.02, 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
