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: Thu, 15 Mar 2012 19:36:58 +0100
Den 18:06 15. mars 2012 skrev Wade Tregaskis <email@hidden> følgende:
> Highly subjective, though, I recognise that. I think we've pretty much run
> this discussion to its end now, and it doesn't appear I've swayed you.
> That's okay.
Yes we have, but you have actually swayed me... :)
You made me think of how we could have it both ways. I think perhaps
what would be cool, is if the responsibility to achieve concurrency
was given to the controllers or models instead of the views/event
handling system. What if each model object could formally specify
which of its KVC properties depend on some shared memory, and which
only depend on the object's internal state? In that case the
controller might see that all the document's properties are free from
such constraints, and can be set in a separate thread. But that would
require the controllers sharing some knowledge between them, so
perhaps the thread handling could be done by NSObject's implementation
instead, if that wouldn't cause more overhead in the KVC methods. I
know you can specify some properties as asynchronous, but I haven't
even looked into what that means if you implement the getters and
setters yourself. I haven't done much Obj-C programming for a long
time.
What I mean is, what if there was some abstracted way of just
registering/reporting the concurrency constraints (or dependencies if
you like) for some object, and let the bindings system make sure the
getters and setters are called in the right thread, without having to
actually implement all the boilerplate code to handle the threading
yourself. If the object doesn't specify any such constraints or policy
then the setters are always called in the main thread, because that
will always be safe. Just a very crude thought, really! I haven't
given this much thought and perhaps there are very good reasons to
avoid such an idea. But with such a system, your application's
threading strategy wouldn't be dependent on some predefined model, and
of course you could just not specify any constraints, and handle it
all yourself if you like. Just a very crude thought. But in practice
that would still mean single threaded by default, which I think is
alright, because if you expect multiple threads, and everything is
done in one thread, everything will still work. The opposite is not
true.
But this has been an interesting discussion, after all! Thanks for the
discussion.
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