Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!texsun!texbell!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Message-ID: <-8V4K33@xds13.ferranti.com>
Date: 23 Jul 90 18:22:14 GMT
References: <24719@nigel.udel.EDU> <878@sce.carleton.ca>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 30

In article <878@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes:
> For example, it used to be, that when FS
> needed to generate a SIGPIPE, it would send a message to MM. The problem
> was, that MM could have been simultaneously trying to send a message
> to FS via. tell_fs. Deadlock!

This isn't caused by multi-tasking in the kernel. It's caused by the
kernel IPC being implemented using rendezvous rather than message queues.

> This is all far too complicated, and it would all go away if MM and
> FS were not separate tasks.

Or if messages could be queued.

> Note that when you get rid of all the extra tasks, you
> can dump a fair chunk of duplicated code (e.g. printk only needs to be
> loaded once, not thrice),

Shared libraries would solve that problem. And you don't need sophisticated
memory management hardware to support shared libraries... AmigaOS does it
and a stock amiga has NO MMU.

MINIX is deliberately designed to be a teaching system, and it's not a
good system to use as a paradigm% for all message-passing operating systems.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
<peter@ficc.ferranti.com>

% I'm using paradigm in its original sense, of an ideal model.
--