On Apr 28, 2014, at 2:53 PM, Jens Alfke wrote: > Looks like a dispatch_semaphore intentionally crashes (a sort of assertion > failure) on deletion if its current value is less than its initial value.
> … semaphores don’t want to be disposed while their current value is less than > the initial value. But I don’t see why that would be a problem; it happens > naturally in some use cases. For example, from the docs, "Passing a value > greater than zero [for the initial value] is useful for managing a finite > pool of resources, where the pool size is equal to the value.” Which is > basically what I’m doing (see below; the ‘resource’ in this case is available > space in the queue.) But if this pool gets dealloced while it has resources > still in it, which is fine, the semaphore will (intentionally) crash. > > I’m working around this by having my object’s -dealloc method call > dispatch_semaphore_signal once per remaining resource, but that’s a hack. I’d > like to know if I’m misusing dispatch semaphores, or overlooking a problem in > my code. I’m thinking of just tossing this out and rewriting it using an > NSCondition. I've seen this discussed before, but I don't remember where. One of the Apple engineers acknowledged the issue. This check is not done (or not effective) if the semaphore is created with a value of 0. So, the workaround is to create it with a value of 0 and then call dispatch_semaphore_signal() to increase the value up to the size of your resource pool. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
