From: James Courtier-D. <Ja...@su...> - 2002-09-29 06:26:08
|
Guenter Bartsch wrote: >hi miguel, > > > >>>well - one consequence of async events is that they cannot be "answered". >>>the old synced events can contain "answer" fields which are filled out by >>>event listeners and the sender can check out the answer as soon as >>>send_event returns - not sure if any module really needs this, though. >>> >>> >>i think the only module currently using this mechanism is >>mpeg_demux_block for obtaining the next mrl. since our dvd plugin >>doesn't need the concept of seamless branching, we can probably get rid >>ot that. >> >> > >ok, another hack gone :) > >btw: couldn't report_codec_cb be replaced by an event as well? > > > As a general observation, it seems that the terms sync, async, events and callbacks are being used wrongly. The current setup has callbacks. The current "events" api is really just a fancy blocking callback. I.E. Just a callback with multiple "backs". A proper "events" mechanism would be done in the same way as "window events" work. For this each window has it's own event queue. When a mouse movement or click happens, and events is sent, in a "fire and forget" method that is non-blocking, routed to the correct window and then sits in the event queue for that window until that window's event queue handler gets CPU time to process it. So, for xine, each plugin would behave like a window and have it's own event queue. As a general note, do we really NEED events at all ? Could we just use callbacks ? Cheers James |