[gmpi] Re: GMPI req's draft 1 for review.
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2004 12:14:48 -0500
Angus Hewlett asked me to pass on some observations based on his
experiences with AU. These seem relevant mostly to OS X, but they
raise issues that exist for other platforms (e.g. colormap allocation
under X Window, event loop reentrancy with many GUI toolkits,
etc. etc). I agree with Angus that some of this stuff has to be
specified clearly so that the eventual implementation obeys clear
rules.
----------------------------------------------------------------------
Just wanted to chip in on one area that seems to be missing from the
spec which is proving to be something of a pain in AU, which is the
handling of process-global variables and contexts used by the system APIs.
Essentially the problem is something like this:- the Mac Carbon API has
several process-global variables controlling various contexts - the most
important ones are the current graphics drawing port, and the current
resource file context.
However, AU does not specify too well what happens to these when control
passes from plug to host. In plug-in code, it's generally easy enough,
and adequate, to set your context when you get control in the UI thread
and restore the context when you return control in the UI thread.
Unfortunately, it's not quite that simple:-
- Some calls may be made from either thread, and modifying those globals
from the DSP thread will cause crashes.
- Some hosts are really unaware of this problem. Mostly that's fine, but
if the plug-in makes a system call from its UI thread which in turn
causes the message loop to be run (e.g. popping up a dialog), then host
functions can be called with the plug's contexts set in the globals...
result? graphics corruption and crashes.
- Some plug-in developers are not aware of the problem, because it's not
the kind of issue that will be familiar to people whose background is
writing DSP code or monolithic apps, and there's no mention of it
anywhere in the AU documentation.
Essentially, the solution is to make both plug and host vendors aware of
this problem, and set a rule in the spec for both sides that the
resource contexts must be set and used for the shortest possible length
of time, and only ever in a single thread, and that ideally no
message-loop-using functions be called while the context is set
(although in practise if everyone follows the save-set-restore rule
properly, that doesn't matter).
This is primarily a GUI issue, but because resource contexts in
particular are used for other things besides windowed-GUI (string
tables, wave tables...), it should probably be addressed before we get
to GUI.
Regards,
Angus.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts: