Re: audio unit deinstantiation thread
Re: audio unit deinstantiation thread
- Subject: Re: audio unit deinstantiation thread
- From: Brian Willoughby <email@hidden>
- Date: Thu, 14 Jul 2011 17:16:59 -0700
On Jul 14, 2011, at 16:09, andre wrote:
On 15.07.2011, at 00:24, Jeremy Todd wrote:
I can see how it's natural to write hosts that don't use the main
thread to interact with (the non-view part of) Audio Units at all
(indeed one of our own hosts behaved this way for a while during
development), but it's really difficult to do some things in plug-
ins with no guarantees at all about what thread you're on.
Natural?
Objects that require the shutdown of threads, semaphores, and other
multi-threading related objects must be deleted on the same thread
they were created on. It is fatal to signal or delete a semaphore/
lock from a foreign thread. Any host that does not ensure this is
making a huge mistake. Or it is making the false assumption that
all plugins only do basic DSP processing.
I beg to differ on some of these points. Semaphores and locks were
specifically created for signaling between separate threads, so your
claims here are seriously misguided. While there are certainly a lot
of careful threading concerns in CoreAudio API, your comments about
semaphores and locks are not correct.
Brian Willoughby
Sound Consulting
_______________________________________________
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