Subject: Re: [linux-audio-dev] API design again [code]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la loka 09 1999 - 17:55:32 EDT
>> this still seems unclear to me. suppose i am a MIDI input thread, and
>> I wake up from select(2). i read the available data. what do i do now?
>> how do I generate an event_t that can be inserted into the relevant
>> queues passed to plugins ?
>
>You qm_malloc() some memory for your new event (will be from shared memory if
>the destination is on the same machine), you fill it in and "send" it to your
>local event port.
OK, now we're getting somewhere. Not very far though :)
So the event is now queued in my local event port. What causes it to
become available to the engine, and thus get delivered to the plugins?
As for "shared memory" - you bet its in shared memory - thats why I'm
talking "thread", not "process".
>Regarding the flushing of the heap buffers you use: As you don't have cycles,
>there will be no natural interval for sending the current buffer off to the
>garbage collector for the context of the event port. What will happen is just
>that the buffers will be left around, and you'll implicitly pass them to the
>garbage collector when they're full.
>(Note: "Sending to the garbage collector" is a bit simplified. A buffer will
>first move to the "queue of buffers to be used" of the real destination event
>port. From there, the buffer is returned to the global heap when it's been
>parsed by the destination plug-in or client, and is no longer needed.)
ah. now we get more complex still ... how can the plugin or client
possibly do this without a spinlock ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST