Linked by Thom Holwerda on Thu 18th Nov 2004 10:19 UTC
QNX I think that everyone reading OSNews will have heard at least something about QNX. You can regard this article as an introduction, but also as a review, and as a "Is-QNX-Ready-For-The-Desktop? article". To start off, I put together a short explanation of the merits of using a microkernel. Let me start off by saying that QNX Software Systems (QSS) does not aim towards the desktop with their Neutrino RTOS.
Permalink for comment
To read all comments associated with this story, please click here.
QNX message passing _is_ synchronous
by teletype on Thu 18th Nov 2004 20:59 UTC

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