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 10:21:02 +0200
On 15.07.2011, at 02:16, Brian Willoughby wrote:
On Jul 14, 2011, at 16:09, andre wrote:
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.
Ok, "signal or delete" is certainly wrong, I should have said "delete"
only.
I am not talking about the regular communication between threads, I am
talking about the /destruction/ of the communication objects, i.e.
semaphores, queues, threads, IPC connections, pipes, listening
sockets, etc. Building these up (launch) and tearing them down
(shutdown) is a critical procedure that must not be subject to race
conditions.
I've seen a lot of trouble with my plugins, which involve a lot of
threading and inter-process communication, until I finally ensured
that they are always created and deleted on the same thread.
Andre
_______________________________________________
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