Re: [linux-audio-dev] API design again [code]

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] API design again [code]
From: Paul Barton-Davis (pbd@Op.Net)
Date: la loka   09 1999 - 10:40:15 EDT


>typedef unsigned int event_code_t;
>#define EV_CLASS_MASK 0xff000000 /* EVC_SYSTEM, EVC_CONTROL,... */
>#define EV_FLAGS_MASK 0x00ff0000 /* EVF_REQUEST, EVF_REPLY... */
>#define EV_KIND_MASK 0x0000ffff /* Exactly what event is this? */
>
>struct event_t;
>
>struct event_port_t {
> qm_heap_t *heap; /* For dynamic allocation */
> event_t *events; /* First event */
>};
>
>struct event_t {
> event_t *next;
> event_time_t time;
> event_code_t code; /* What is this? */
> int size; /* Number of data bytes */
>};

>Nice, simple, and perhaps the extra copying doesn't make much
>difference, considering the added complexity when trying to avoid it?
>After all, events ar e supposed to be pretty small most of the
>time... And moving pointers around is data copying as well.

i think you're going to be missing something pretty critical, and
something much more expensive that any of this data
copying/conditional stuff you're worrying about.

where do the events come from ? that is to say, in a multi-threaded
system, what actually allocates, deallocates, and otherwise sets up
event_t's for their use in the API ?

if its the engine thread itself, how do you get events delivered to
it? i see two possibilities, both of them bad.

  1) you're imagining that, external "h/w" events (e.g. MIDI i/o, GUI
     events, etc) get handled by a plugin run by the engine thread.
     In the case of MIDI-like stuff, this gets rid of sample accuracy,
     since we can't notice the event till we execute the plugin, which
     happens once per control cycle. In the case of GUI stuff, its
     even worse, since at least one well known and widely utilized GUI
     system (X Window) isn't (properly) multithreaded, and you will crash.

  2) h/w-driven events get noticed by other threads, and are then
     delivered to the engine thread somehow. this seems to imply some
     wholly different event-type-specific-API. seems like a bad idea,
     given that this event system is supposed to be generic.

So, it seems likely to me that we're going to need to be able get hold
of event_t's from multiple threads. In that case, how do you ensure
atomicity on the *next pointer, and on *heap ?

if qm_thread_t is actually as simple as you propose, you can't use
lock free queues, and likewise for the event_t *next pointer.

so somewhere in there you're going to have one or more locks that need
to be taken, and the cost of this will far outweigh the other stuff
you're worried about.

or have i missed something fundamental and obvious again ? :)

--p


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : ke maalis 08 2000 - 13:40:59 EST