[gmpi] Re: GMPI req's draft 1 for review.

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: