Nick Maclaren wrote:

But your last remark is correct. It isn't hard to separate GUIs
into multiple components, separated by message passing (whether
using thread primitives or not), and those are a doddle to schedule
on multi-core systems. And that is the way that things are going.


I'm not sure that the gui by itself is enough to justify a multi-core
cpu. And there are problems enough in multi-threaded gui, even apart
from deadlocks caused by inexperienced programmer mixing threads and OO
callbacks. Consider mouse events queued before but received after a
resize operation. The mouse coordinates are in the wrong frame of reference
and all wrong. Gui designers design as if the event queue was = 1 at all
times.

What would more likely to utilize concurrency would be the database like
Longhorm filesystem that MS is supposed to be doing. Except that I don't
think MS has the expertise to do lock-free concurrent programming like that.
If they have, they've been keeping a low profile.

Joe Seigh