Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- Subject: Re: [Q] Why is the threading and UI updating designed to be done only on a main thread?
- From: Per Bull Holmen <email@hidden>
- Date: Wed, 14 Mar 2012 17:52:26 +0100
Den 17:19 14. mars 2012 skrev Wade Tregaskis <email@hidden> følgende:
> The reality is of course more of a compromise. It's quite common to do drawing across multiple threads, though you still synchronise the final "blits" around a single thread (i.e. the main thread).
Isn't that still legal? I remember it was legal in the old days of Mac
OS X, and I did it once, and had no problems with it. From what I
recall, I decided in the end that I had gained nothing from it, apart
from added complexity. I'd think that would be less useful nowadays,
since the drawing is supposed to be offloaded to the graphics card.
Receiving events on other threads were discouraged, because things
could happen out-of-order.
> Likewise even event handling is often effectively multi-threaded, because you dispatch from the main thread to a variety of tasks, queues or worker threads.
But then you are receiving the events on the main thread? What do you
mean? If you receive events on the main thread, and dispatch the work
to be done to other threads, I'd say that is quite in line with how
things are currently done on OS X.
Per
_______________________________________________
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