Newsgroups: comp.os.minix
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!IDA.ORG!wheeler
From: wheeler@IDA.ORG (David Wheeler)
Subject: Re: User Process Message-Passing in Minix
Message-ID: <1991May24.214312.20952@IDA.ORG>
Organization: IDA, Alexandria, VA
Date: Fri, 24 May 91 21:43:12 GMT

I wrote:

%The original version of Minix did not allow _User Processes_
%to pass messages to OTHER user processes.

philip@cs.vu.nl (Philip Homburg) replied:

% Please DON'T DO THIS. May be this is too loud and I should whisper "please,
% don't do this" but you are looking for trouble.

I agree with some of the problems you list, but I'd like to try to fix
them.. and thanks for listing some.  I think what's needed to make it
work is a fair amount of thinking time & relatively little new code.
It's essentially like thinking up & verifying communication protocols!

There are LOTS of operating systems and languages which already support
user-to-user message-passing to some degree, so I disagree that it's
_automatically_ a bad idea.  They include Mach, QNX, System V, Berkeley, Ada.
Many others, too.  Communicating sequential processes goes back to Hoare's
work & is a very useful capability!

This is a fundamental new capability, though, so I completely
agree with you that it has to be thought out carefully.

What's definitely NOT a good idea is:

% And, last but not least, you can do it with fifos.

You mean pipes, unnamed or named, right?

I want to support user-level servers to other user-level programs.
These servers can be started up later, and (rarely) taken down
(for example, to replace them with a new & improved version).

Unnamed pipes just don't work in this case; there isn't a shared
parent who can create a pipe between the client & server.

Named pipes are a uniformly AWFUL way to do client/server
communication.  The server DEFINITELY doesn't know who sent the
message, the size of the sent message isn't known, and
the server has to do all sorts of work to do named pipe
management.  All of which is pointless, since the OS itself ``knows''
about all the tasks & is already based on a message-passing system.


= There are a few problems:
= What to do with signals. You didn't get a message but you got a signal.

That's already in the CURRENT SYSTEM.  After all, you can send_receive
to MM or FS.  You can either be sending, server hasn't gotten to you yet,
or receiving, your message was received but you haven't been replied to yet.
I do need to examine this more carefully, though -- is what the current
system does now appropriate?

= What if somebody is sending to you and you die. The kernel doesn't check.

Actually, the kernel DOES check.  Page 473, line 1991.

= How does a server find out his process number.
 getpid().

= How do you send messages larger than about 32 bytes.

 Some applications won't need more.  For those that do:

  1. Send multiple messages. or,
  2. Modify MM and operations for memory-to-memory moves possible.
     Clearly this would have to be "agreed to" by both processes,
     but other OS's do exactly this (I believe Thoth does; anyone know
     for certain?).

= How do you know who sent the request, no userids can be checked.

  The kernel gets the pid's from the process table (MM's main.c
  does this).  Perhaps calls need to be added to get
  the process id of the one who sent to you, and/or a uid given a pid.
  Those would be trivial to add!

--- David A. Wheeler
    wheeler@ida.org

