On 25 May '08, at 2:40 AM, Thomas Davie wrote:
I hate to say this, but any form of delay here is the *wrong* way to do this. You already know you have a race condition, all you're doing is making it so the race condition will work out in your favor 99.99% of the time. There are still exceptional cases where the OS will be busy doing something and your 0.1 second sleep will not be enough to sort it out. Instead of doing this, do your threading properly, and get your locking right.
This is correct advice when it comes to interactions between multiple threads; but Steve's problem involves only a single thread. The timing here is measured in iterations of the thread's runloop, not in clock time. As Dmitri put it:
From 10.4 on fetch: results are delayed until the next iteration of the run loop
So I believe that any technique that cranks the runloop through at least one iteration will solve the problem, and that includes any sort of timer or perform-after-delay. (I often use performAfterDelay: 0.0, though it looks nonsensical on first glance, to delay some action until the very next runloop iteration.)
—Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
