I could be wrong, but it seems safe if the signal or semaphore only holds the lock long enough to update a small, finite amount of memory. I assume that the lock is taken right before writing to a 32-bit value (64-bit at most) and then unlocked right away. I don't see how that could block for very long. Of course, a look at the mach source is required to make sure something worse isn't happening. In other words, I doubt that memory is being allocated while the lock is held, because the signal or semaphore should have already been allocated before the lock is taken.
Caveat: I haven't looked into these details in quite a while. Brian Willoughby On May 23, 2016, at 7:20 PM, Michael Tyson <[email protected]> wrote: > Anyway - any other thoughts, before I convert my code back to using main > thread polling? Am I being too precious about this? Have I been wrong the > whole time, and locks are actually fine in this context? _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
