OSNews

1) Multithreading is just an event handling system where there kernel provides various message queues. It gets most "useful" with preemptive scheduling. This can all be implemented manualls if you feel like it. [ Prof. N Wirth wrote a very readable paper against MT years ago. ] 2) Async IO is multi-threading with second class threads and a very inflexible scheduler. If you don't carefully lock data structures then the IO handler can access inconsistent data structures, if you do lock them then youve just (loosely) synchronised your async IO handler. :-) 3) There is no such thing as async messaging. The appearance of Async messaging is achieved by having a queue managed by a separate (and synchronous) worker thread enqueue and dequeue messages. The policy used by the worker thread to handle full queues is important. If the policy is to drop messages, and the worker thread is buried in the kernel and the policy is hard coded in the thread, then you end up with an unreliable OS. 4) Having the kernel allocate message queues is a _bad_ idea, it makes proper resource accounting very hard. I believe the late Prof Jochen Liedtke was correct in his L4 kernels in choosing only sync IPC. However I believe he was mistaken in not providing a semaphore for shared memory synchronisation. [ Note MS Windows has both PostMessage() and SendMessage(), the later is at least partly synchronous. ] 5) Synchronous messaging (and a predicatable scheduler) makes debugging easier, as it is possible to predict what happens. 6) Handling locks is tricky, which is why well designed languages provide high level synchronisation primatives where the compiler can verify many basic properties (e.g. locks get unlocked), and where code analysis can verify several more (e.g. consistent nesting) allowing formal analysis of deadlock freeness (what a word :-). 7) The idea of separating UI code from application code is not new. Its just a shame that X did not include a proper extension mechanism.