Messages in this thread | | | Date | Mon, 21 Jun 1999 11:36:54 +0000 | From | Bernd Paysan <> | Subject | Re: Some very thought-provoking ideas about OS architecture. |
| |
Linus Torvalds wrote: > In short: message passing as the fundamental operation of the OS is just > an excercise in computer science masturbation. It may feel good, but > you don't actually get anything DONE. Nobody has ever shown that it > made sense in the real world. It's basically just much simpler and > saner to have a function call interface, and for operations that are > non-local it gets transparently _promoted_ to a message. There's no > reason why it should be considered to be a message when it starts out.
This is partly right, and partly wrong. Actually, some light-weight message passing protocols can be cheaper than function calls. A function call to a kernel function requires two state transitions (user->kernel and back), and two context switches; since the kernel wants to massage different data than the user process, it also has an effect on the cache.
Message passing can make this cheaper, if (and only if) your messages are handled asynchronously. Put a bunch of messages into your shared memory message buffer (simple *ptr++ = id; *ptr++ = arg; ...), and when you are done, do the one state transition and context switch, and let the kernel handle all the requests at once (also simple: next message is goto *handlers[*ptr++]; Message code does arg = *ptr++;...). The communication overhead in a good designed active message system can be below the state transition overhead in a classical OS.
Counterside: works only if your OS is designed to deliver asynchronous results, and if your app is programmed to use that. In other words: forget about blocking read/write calls. Works much better for services like X Window than for Unix-like OS services. The point is that you must restructure your app to be message-handling, too. I.e. a web server's frame would look like
switch(get_next_message(queue)) { case incoming_connection: accept(connection); break; case opened_connection: read(request); break; case request_read: parse(request); send_answer(request); break; case request_sent: close(connection); free(request); break; ... }
Note that all the OS-related calls are unblocking and are served (as a bunch) when the app has no more messages to handle - or the outgoing message buffer is full. Wraping messages around an OS that is designed to have services as function calls is a complete waste of time; so in this respect, Linus is right. Masturbation is only effective if you have a sperm bank.
-- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |