[gmpi] Re: Topic 5: Threading

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 10 Apr 2003 12:58:04 -0600



Angus F. Hewlett wrote: 

I propose that all DSP objects are treated as single-threaded. Forgetting
GUI for a moment, there's IMHO no real need for a host to be calling in to
plug-in code from multiple threads. A simple host can schedule any
parameter changes to take effect synchronously with the next graph-level
process-callback (this will not compromise UI responsiveness much or at
all - visual feedback latency is not noticeable until in the region
50ms!); a more sophisticated host may wish to have locks relating to
individual objects.

Can anyone give a good reason why DSP objects need to be callable from
multiple threads?

I can definitely see calling to ask a plugin for its parameter value on multiple threads. I may not even be running the process thread, but want to get/set parameters or programs on the plugin. I do not want to have to start a process thread just to do this, or be required to always keep a process thread running.
I am also definitely not going to create/destroy plugin objects on the high priority process thread. This would even be illegal on some platforms.
I think is is very unreasonable to require that all plugin calls are on one and only one thread. This would make the plugins difficult to impossible to host in many sitautions.


--
Mike Berry
Adobe Systems


----------------------------------------------------------------------
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:

  1. Home
  2. gmpi
  3. Archive
  4. 04-2003