Re: Dispatch IO
On Aug 9, 2013, at 10:31 , Seth Willits sli...@araelium.com wrote: One of my thoughts is to set the handler interval and check for the data size to be over my memory limit and if it is, set a flag and stall generation until it drops back below the memory limit which I would know the next time the handler is called and the data size is below the limit. I'm not sure if it this is a *good* strategy, but I can't think of anything else. I use GCD counting semaphores for this. The precise configuration depends on the structure of your data producers (whether each is a separately-queued GCD block, for example) and how data production operations are initiated (whether each creates its own successor, for example), and you may need multiple semaphore to control the data flow, but it's a very flexible approach that's also simple to implement. The only awkward part might be ensuring that things can be cancelled properly. Incidentally, keep in mind (from an earlier discussion on this list) that GCD semaphores initialized with a count greater than 0 will complain (incorrectly, IMO) if the current count is not the same as the initial count at deallocation time. The workaround is to create the semaphore with a zero count, and to immediately increment it to the desired value. ___ 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
Re: Dispatch IO
On Aug 9, 2013, at 11:09 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Incidentally, keep in mind (from an earlier discussion on this list) that GCD semaphores initialized with a count greater than 0 will complain (incorrectly, IMO) if the current count is not the same as the initial count at deallocation time. The assumption is that if you're destroying the semaphore and the count doesn't match then there is some worker still in progress that is going to signal the dead semaphore later. Detecting this error at semaphore destruction time instead of crashing at dead-semaphore signal time is a safety feature. The workaround is to create the semaphore with a zero count, and to immediately increment it to the desired value. I believe this is exactly the intended solution. If you create with a positive count, you're assumed to be doing balanced operations. If the count starts at zero you can use whatever crazy unbalanced algorithms you like. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Re: Dispatch IO
On Aug 9, 2013, at 11:09 AM, Quincey Morris wrote: One of my thoughts is to set the handler interval and check for the data size to be over my memory limit and if it is, set a flag and stall generation until it drops back below the memory limit which I would know the next time the handler is called and the data size is below the limit. I'm not sure if it this is a *good* strategy, but I can't think of anything else. I use GCD counting semaphores for this. The precise configuration depends on the structure of your data producers (whether each is a separately-queued GCD block, for example) and how data production operations are initiated (whether each creates its own successor, for example), and you may need multiple semaphore to control the data flow, but it's a very flexible approach that's also simple to implement. The only awkward part might be ensuring that things can be cancelled properly. So I'm at least not the only doing it this way. Ok. It seems like an API extension would be logical and very useful here. Incidentally, keep in mind (from an earlier discussion on this list) that GCD semaphores initialized with a count greater than 0 will complain (incorrectly, IMO) if the current count is not the same as the initial count at deallocation time. The workaround is to create the semaphore with a zero count, and to immediately increment it to the desired value. I'm in agreement with everything Greg said here. -- Seth Willits ___ 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
Re: Dispatch IO
On Aug 9, 2013, at 12:37 , Greg Parker gpar...@apple.com wrote: The assumption is that if you're destroying the semaphore and the count doesn't match then there is some worker still in progress that is going to signal the dead semaphore later. Detecting this error at semaphore destruction time instead of crashing at dead-semaphore signal time is a safety feature. I believe I mentioned, the last time this came up, that I know of at least one case where matching isn't possible: AudioQueues. If the resource being counted is AudioQueueBuffers, stopping the queue discards any buffers that have been passed to the framework, without the callback being called to indicate this (and it's documented to behave this way). you can use whatever crazy unbalanced algorithms you like Hey, buddy, that one ain't *my* crazy algorithm! ;) However, the alternative approach is a fine, er, alternative. ___ 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
