Closed gmckenzi closed 12 years ago
Builds fine, looks more simple. I'm not that sure of myself with GCD yet, so thanks for your help!
No worries. You did all the heavy lifting. :-)
Note however that my proposed changes mean that a second caller to rename won't start until the first rename is finished. Whereas in your original code a second caller rename could queue-up before the first one finished -- it simply would wait for the previous rename to finish. In the end, the behaviour is effectively the same.
Gavin McKenzie
On 2012-02-11, at 10:56 AM, Oliver Drobnik wrote:
Builds fine, looks more simple. I'm not that sure of myself with GCD yet, so thanks for your help!
Reply to this email directly or view it on GitHub: https://github.com/Cocoanetics/DTFoundation/pull/2#issuecomment-3921414
Damn. I got my explanation wrong. Let me try again.
In the original implementation, additional callers would wait until all queued renames were finished -- which is exactly what your code comment said. Which, could (in theory) mean that if 20 renames were queued, even the first rename operation would have to wait for the 20th queued rename to finish. That potential worried me, of having basically a block-wait on all the renames.
With the dispatch_sync approach each rename only has to wait for the previous rename to finish.
Gavin McKenzie
On 2012-02-11, at 10:56 AM, Oliver Drobnik wrote:
Builds fine, looks more simple. I'm not that sure of myself with GCD yet, so thanks for your help!
Reply to this email directly or view it on GitHub: https://github.com/Cocoanetics/DTFoundation/pull/2#issuecomment-3921414
Just a thought. Wouldn't doing a dispatch_sync on the rename achieve the same behaviour with less code? Warning: I haven't tried compiling/running this. Just made a quick edit directly in GitHub.