Path: utzoo!mnetor!uunet!mcvax!ukc!stc!idec!camcon!mfr
From: mfr@camcon.uucp (Mike Richardson)
Newsgroups: comp.misc
Subject: Re: Message based OSs (was "Re: GNU Manifesto")
Message-ID: <1258@titan.camcon.uucp>
Date: 25 Feb 88 10:41:18 GMT
References: <1447@sugar.UUCP> <227@gandalf.littlei.UUCP> <198@oravax.UUCP>
Organization: Cambridge Consultants Ltd., Cambridge, UK
Lines: 35
Summary: Message passing versus procedural systems .. what!?

In article <198@oravax.UUCP>, clay@oravax.UUCP (McFarland) writes:
>
> Theoretically, message-based architectures are inherently less buggy
> than procedure-call architectures; one reason is that control-flow
> bugs are confined to the entity which receives a message. However,
> you must really design a message-based system. If you produce a
> message-based system by holding a procedure-call system in your
> hands, facing in the direction of Alan Kay, and whispering "message"
> (thus magically changing "calls" to "sends") what you have is a kludge.
> The kludge will contain all previous bugs + bugs in the message handler
> + bugs resulting from unexpected interactions between the message
> structure and the existing procedure structure.

Unless the system is programmed in a non-procedural language, such as PROLOG,
then it is bound to have a procedure-call architecture; you call a procedure
to get something done for you, be it send a network message half way round
the globe, or to find the length of a string.

Are you referring to message-passing systems verses shared memory (or monitor
based) systems? Since these can be shown to be functionally equivalent (each
can be similuated using the other) I would have though that they are
bug-equivalent as well, theoretically at least. It seems to me that message
passing systems have two advantages, however:

(a) The tendancy is to wrap up logical groups of system functions (file
system, network interfaces) into separate processes, rather than to lump
them all into the kernal (viz-a-viz UNIX). It is much easier to replace
or augment such systems.

(b) Message passing systems map onto multiprocessor machines better. Use
of (physical) shared memory is all very well, but eventually you run out
of memory bandwidth, which forces a separate memory solution, hence messages.

These opinions are my own, and not necessarily those of my employer. Hope
this doesn't take so long to cross the Atlantic ......