Q: messagesystem

Hello,

I got questions I can't answer myself:

1) Correct me if I'm wrong:
As far as I understood, a request like "read" is done by turning the
given buffer to be the area where the read bytes go and send out a
appropriate message. Is there any case yet, where multi segment
messages are generated?

2) A message is transfered to the receiver by making segments from the
buffer(s) and mapping them to the address space of the receiver. There
is no copying. (?)
Assumed one task of a process 1 send a message to a second process and a
second task of process 1 modifies the data of the message later. What
happens? Is this a caught violation, is the data process 2 will read
modified or anything else?

3) The rule is: all what can be done in the library goes to the
library. So for every kernel service there is a good reason to make it
a kernel service. But I can't find a good reason for msg_connect,
msg_accept, msg_disconnect (and msg_err). In my oppinion it could be
done by the library and under certain circumstances it could be left
out.
- msg_connect/msg_accept just handles the connection. Easy to code in
  the library or did I miss some point? And could be left
  out if a little different protocoll would be used.
- msg_disconnect: same as above. For the exit() the server had to send
  it to all clients at once (library code).
  A small problem comes up for processes which dump core. But that
  should not be a problem.
- msg_err is a complete different question, but I can't see any
  problem.

4) A non-blocking send/receive pair would make it easier to build a
level with async services between the file-like level and the
kernel. We feel to need this. Is there something to say against it?

One more idea about kernel services: The kernel entry is expensive (in
intel systems at least). The L3-system saved a lot of time by
providing a additional service reply_and_receive_next. I think it
would be a good idea to provide a library function like that and
prefer the use of it over the use of the single calls. So a later
optimization by a additional kernel service won't hurd.

/Joerg
-----------------------------------------------------------------------------
Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de
Rietzstr. 32b | (eventually try: jw@ibch50.inf.tu-dresden.de
01139 Dresden | or jw6@mail.inf.tu-dresden.de)
Germany |

WWW: <a href=http://www.inf.tu-dresden.de:~jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
Received on Wed Oct 19 07:14:25 1994