Linked by Thom Holwerda on Thu 18th Nov 2004 10:19 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Hello there,
Citing the article:
A post by Bernd Paysan, though, in alt.os.multics explained why QNX performs better than other microkernels:
"[...] Unix's syscalls all are synchronous. That makes them a bad target for a microkernel, and the primary reason why Mach and Minix are so bad - they want to emulate Unix on top of a microkernel. Don't do that.
If you want to make a good microkernel, choose a different syscall paradigm. Syscalls of a message based system must be asynchronous (e.g. asynchronous IO), and event-driven (you get events as answers to various questions, the events are in the order of completion, not in the order of requests). You can map Unix calls on top of this on the user side, but it won't necessarily perform well."
If you read the "QNX System Architecture" document and took a quick look at QNX's C library implementation, you would see that its read/write are just wrappers to MsgRead/MsgWrite. Message passing in QNX is fully _synchronous_ (if you don't count those ``enhancements'' in 6.3, aimed primarily at better mqueue manager implementation): MsgSend will send the message to the channel and wait for the reply from the server. No buffering, no "callbacks", and only limited usage of MsgDeliverEvent and signals.
And AFAIR, message passing in Mach is asynchronous (in contrary to QNX).