Re: [xine-devel] events/callbacks: global or per-stream?

[<bar...@t-...>]

hallo miguel,

> Yes, i agree it's pretty bad hack we have and since you are checking all
> the current event utilizations let me ask you something: have you found
> any of those to really require the current asynchronous behaviour? that
> is, blocking the caller until the event has being processed?

humm - maybe you're right, this is not really needed.

oki, so maybe one async event mechanism is sufficient - but this means
that a mechanism to reliably (deep-)copy events is necessary.

> i must say i don't like the idea of requiring all event users to have to
> create/destroy their own listening threads. imho event sending and
> receiving should be a simple mechanism to use.
> 
> What about a new xine-engine thread just to dispatch events? all
> listeners could still register their event handlers the same way they do
> now. the difference is that it would run from this special thread
> context and never at event caller's context.

i can still imagine situations where this can lead to deadlocks - mainly
because i think such a thread is aequivalent to having one big lock
around all event queues. it would enforce events to be processed in a
certain order while having multiple threads each reading their queues
would not enforce this.

> since event mechanism is used to send few data not much frequently (we
> would never use it for sending video data for example) the
> performance/memory impact would be hardly noticed. a small price to pay
> for a clean mechanism imho.

allright - so what is it that you're proposing? something like

typedef union {
  uint32_t                         type;   /* event type (constants see
above) */
  xine_stream_t                   *stream; /* stream this event belongs
to     */

  void                            *dynamic_data;
  int                              dynamic_data_length;

  xine_input_event_t               input_event;
  xine_ui_event_t                  ui_event;
  xine_frame_format_change_event_t frame_format_change_event;
  xine_audio_level_event_t         audio_level_event;
} xine_event_t;

this would mean that e.g. strings could be stored in the dynamic data
field and reliably be deep-copied.

> > 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 ?
> 
> looks a good idea. what's the other option? requiring a new stream_t to
> be created, closing and reopening video and audio drivers?? i think we
> did something like that in the past and it sort of sucks... 

closing and reopening output drivers is always necessary, i think (ok,
well at least re-allocating frames, that is) - but generally you got the
idea, a new stream_t has to be created for every new mrl because

xine_stream_t *xine_open (xine_t *stream, const char *mrl,
			  xine_ao_driver_t *ao, xine_vo_driver_t *vo);


is the only way to create a stream_t. for now, i think i'll implement
this scheme, maybe later we can implement another call that allows the
mrl to be changed for an existing stream_t. but at the moment i'd like to
get to compiling and soon-after working code as quickly as possible.

cheers,

   guenter

--
Q:  How many existentialists does it take to screw in a lightbulb?
A:  Two.  One to screw it in and one to observe how the lightbulb
    itself symbolizes a single incandescent beacon of subjective
    reality in a netherworld of endless absurdity reaching out toward a
    maudlin cosmos of nothingness.