From: <bar...@t-...> - 2002-09-28 15:38:59
|
hallo michael, > > what makes more sense - have event listeners global or per-stream? > > > > same issue with report_codec_cb ? > > I think both should be per stream. > Reasons: > * With our current lightweight event mechanism (which is good enough > for our needs - another thread would be too much) it is better to have > fewer event listeners. humm - this makes me think. first of all, if even-listeners are per-stream it means that we have more event listeners, not fewer. second, while i'm trying to implement the changes i stumbled across the event mechanism - while i never really liked it i now realized how much of a catastrophy it really is. i'm convinced it can't stay that way. the problem is that event listeners are executed in the context of the caller of xine_send_event. this might be fine for xine-internal use, but it is a high risc if frontends are allowed to receive events. if i see things correctly this has lead to the introduction of the finished_thread hack in xine.c. but generally frontends receive all events and can therefore react on any of them. the consequence are simply unpredictable - just imagine an input plugin sending an event and the frontend calling any of the high-level xine-api functions - which could mean that the whole engine is restarted "on behalf of" the input plugin (which could even get disposed as a consequence). so, i think we need a real event mechanism. i'm thinking of something like this: xine_event_queue_t *xine_new_event_queue (xine_stream_t *stream); an event_queue is simple a xine_list plus a mutex+condition which stores xine events until they're received by calling one of xine_event_t *xine_get_event (xine_event_queue_t *queue); xine_event_t *xine_wait_event (xine_event_queue_t *queue); any module wishing to receive events then has to implement it's own event loop, probably as a thread but maybe there are other mehtods as well - no matter what method is chosen, we're sure it is one of the modules contexts the events are received and processed in, not the caller's context. the caller simply calls xine_send_event (xine_stream_t *stream, xine_event_t *event, int size); which will add a copy of the event to every event queue ... which is the part i don't like - mallocing events and copying them is both malloc-stress-testing and cpu intensive, so probably not a good idea. not sure how to get around this. i can think of two solutions, but both have their drawbacks: 1 - block the caller of send_event until all queues have received the event (this the caller's copy of the event is sufficient). this can, however, lead to unwanted deadlocks if the caller holds any locks that are needed to process the event. 2 - try to make all xine_events the same, fixed size (this means that a xine_event_t should have room for a reasonable amount of text - something like a char str[256] field and two or three integer fields) and alloc a bunch of them in advance (pretty much what we do with buffers). personally i tend to the 1st option as it is still lightweight and provides "synced" events just as xine has now. > How is the work with xine_stream_t going? Do you need some help? still looking around and trying to get the whole picture of how the libxine<->frontend interaction works. on the one hand introducing xine_stream_t sure looks like a lot of work, on the other hand most of the problems i encounter should be solved independantly of introducing it or not - examples are of course the event mechanism, but also the global locks and of course i noted that i have to implement my mechanism of waiting for headers to be sent in a thread conforming way... i could use some help, but i'm not sure how more than one person can work on this at this early stage. my hope is to get through with the engine changes as quickly as possible and then convert only one or two plugins of each kind to the new scheme - when i've done this i think we can start together adapting the other plugins and maybe implement some of the new features such as get_*_frame(). of course frontends need to be adapted to the api changes once again. i'm not sure if daniel plans to implement any of the cool new features in xine-ui or if it is finally time for me to go about xine-ui2, but for now i'll stick to gnome-xine. btw: another question is wheter it should be possible to use an existing stream_t and assign it to a different mrl. this would mean quite a lot of effort in xine.c but would allow playback-only frontends to more-or-less operate the same way as they used to ? > I am now thinking myself through the video/audio post layer and if the > API is suitable for that. I hope to come up with some ideas. what is a video/audio post layer? :> cheers, guenter -- Abandon the search for Truth; settle for a good fantasy. |