Re: audio unit deinstantiation thread
Re: audio unit deinstantiation thread
- Subject: Re: audio unit deinstantiation thread
- From: andre <email@hidden>
- Date: Fri, 15 Jul 2011 09:47:37 +0200
On 15.07.2011, at 01:18, Jeremy Todd wrote:
I agree that it's a complete pain when a host doesn't create and
destroy us on the same thread, believe me :). I was just pointing
out that it's natural to instantiate/deinstantiate plugins on the
non-main thread.
Creating a special thread to defend against this situation sounds
interesting, but how can you tell if the host is going to do this to
you or not? I've found that Soundtrack Pro sometimes deinstantiates
us on a strange thread, and sometimes it deinstantiates us on the UI
thread, so our plugins can't reliably predict what it will do.
Always using one's own service thread is safe, but if you want to do
that only for selected hosts, the only way to tell is to make your
observations and hard-code a list. If you're on a host that is not on
your positive list, you need to delegate things to the service thread,
otherwise you can execute immediately.
You an get a hosts name by looking at its bundle path and/or
properties. There are not too many hosts out there, so a positive list
makes sense.
Having a WorkerThread class at hand is helpful for many purposes. I
did it in C++, so I don't exactly know how it would be done in Cocoa,
but basically it is fetching "jobs" from a queue in its main loop and
signaling a semaphore when the job is done, so the posting thread can
continue. You can pass in a context object with arguments and one or
more result slots. Very nice to have.
Andre
P.S: One other ugly thing you get when deleting objects on the wrong
thread is: Race conditions. You may encounter the situation where an
instance is being deleted while it is still in the process of being
constructed. This is impossible when both are done on the same thread.
I still wonder how come that so many host developers do not see this.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden