>>>>> "c" == chromatic <[EMAIL PROTECTED]> writes:
c> On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote: >> >I'm also curious how to write an interface to an existing event system. >> >Being able to write it all in PASM is a bonus. >> >> I don't think it can be all-PASM, except maybe (and maybe not...) >> with a separate thread for the existing event source. To do it in all >> pasm means calling back into parrot from interrupt level, which isn't >> really doable, or have a thread just waiting on events from the >> alternate event system to post into the parrot event queue. c> Another approach may be to expose the PollEvent and WaitEvent functions c> to the event system as alternate sources of events. If I can do that c> from PASM, I think I'm okay. i don't think exposing them is a good idea as they can be broken by user stuff. and see my other reply for another solution to waiting on multiple events without any extra core code. it is very easy and eliminates the need for a group wait op. one problem with a group wait is that you can ONLY wait for that group. what if you wanted to know when group A events are all done and also when group B events are all done? and what if you have other single events floating around? rarely do you just have a single group of events to wait for. my solution works with any combination of events and groups. 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
