>>  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.

That's kind of my point.  For a given single input device, there's a definitive 
ordering of events.  So at some level you have that.  It also makes a lot of 
sense to serialise all input events, on the assumption that it's a single human 
driving them, since most humans expect their keystrokes and mouse actions to be 
interleaved in the same order they performed them in.

At some higher level, those events invariably cause actions to be taken, which 
may be "trivial" (show/hide a view) or complex (load a saved document, perform 
a render, whatever).  It's common practice to farm those off manually, today, 
in Cocoa.  Based on perceived complexity and wallclock time of the task, 
generally.  Not necessarily tied to a particular logical resource (e.g. a 
document).

On the other hand, you could have an event handling framework which dispatched 
events to any of multiple threads/queues/whatever for you.  For example, each 
window might have its own queue.  This actually makes a lot more sense in many 
cases, as a default, since many actions within a single window/document are 
successive, not concurrent.  If they are concurrent, you could then go to the 
trouble of manually dispatching things to other queues, or otherwise realising 
that concurrency.

[[ And if you have multiple windows per document, you could always configure 
them to share the same queue, if that's appropriate. ]]

As others have pointed out, various major systems have done this in the past, 
to varying degrees.  BeOS, for one.  I also believe MFC (Windows, pre-.NET, 
basically) does something like this.  It might seem alien to traditional Mac 
developers, but it's far from exceptional.

Though I say all these merely to emphasise that it's possible.  To actually 
consider revising all of Cocoa around such a new paradigm would be an 
extraordinary undertaking.
_______________________________________________

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to