Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke syys 29 1999 - 15:41:16 EDT
><start of 2 cents>
[ ... at least 2 pounds worth of comments elided ... ]
Just a quick detail to mention, arising from something that just came
up in Quasimodo.
If you assume that one of the targets of communication is a thread
running some of UI, and your further allow for the possibility that
this might be a different thread than the one in which the
communication originates, then you have to be *very* careful about
designing the messaging system.
As long as events which ultimately cause "messages" to be sent are
caused by the UI, then there is no problem.
However, I am just trying to get Quasimodo in shape to handle
automation down the line, and this changes things
substantially. Because X is not now, and probably never will be, truly
thread safe, my working assumption is that only the thread that starts
contact with the server can ever make contact with the server. The
alternative is to use mutexes to guard access to the server, and this
is an incredibly bad idea when one of the threads is a real-time audio
engine, and the other is a UI which might take an unbounded amount of
time before releasing the server mutex.
Why is this a problem ? Because it means that any "event" system that
is based, explicitly or implicitly, on execution of some code within
the same thread that raises the event, or that thinks it can escape
without mutexes around event queues, will likely cause X errors at
some point.
If an automation object decides that its time to post a parameter
change, and we want the UI object to notice it, it is *NOT ENOUGH* to
either (1) put the event on a queue or (2) execute a callback to the
UI code. In the case of (1), we have to grab the mutex around the
queue, which may or may not be a good idea, depending on your timing
constraints. In the case of (2), you have to implement a way to
execute a callback in the UI thread, not the thread posting the event.
There are some workarounds to this, such as always running the
automation code within the UI thread, and/or being very careful to
hold queue-protecting mutexes for a very, very short time. But even
so, you have to be careful. If the engine itself ever generates events
that the UI needs to be notified of, you're back to square one.
I hope its obvious (to all who might need to care) why you want the UI
to execute in a different thread than the engine of an audio system.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST