Hi Jens,
Thank you for your clarifications. I had been left with an unsettled feeling
about the technique.
On 25/5/08, Jens Alfke wrote:
> 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.)
That's a great way to put it, and thanks for yet another useful technique.
Best regards,
Steve
_______________________________________________
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]
