Re: dispatch_semaphore crash on deletion
Re: dispatch_semaphore crash on deletion
- Subject: Re: dispatch_semaphore crash on deletion
- From: Ken Thomases <email@hidden>
- Date: Mon, 28 Apr 2014 15:02:02 -0500
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 (email@hidden)
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:
This email sent to email@hidden