ORG, IPC [pem01]

[Peter Mueller]

Hi,

I want to comment to the main design decision, whether to use synchronous or
asynchronous communication primitives. As Moose will be an oo-os it should be
possible, to provide a basic communication object (note: the object is
part of the kernel). Within an application one can create an instance of that
object, say, COMMUNICATION, something like this:

main() {
  COMMUNICATION comm;
  MESSAGE msg;
  ADDRESS addr1, addr2;

  addr1 = ...             // Initialize destination address
  comm.send(addr1, msg);  // Send the message

  // do something

  addr1 = ...            // Initialize source address  
  comm.receive(addr1, msg, addr2);
  comm.reply(addr2);

  // do something
} 

(Before you start to flame me for these implementation-details, please read on.
I used it, because it's very heavy to draw in ascii nice figures. And I think
with this flow of control I can illustrate what I mean ... and yes! I used 
C++ because I then know what I'm writing. :-)

The program above demonstrates the lowest level of IPC. A "normal" user will
not see this in this way, he will use ROI, where a method of a remote object
is directly invoked. Nonetheless, ROI must be mapped to such IPC primitives
(which we call "stubs" or communication objects, as above)

Now my idea: I'm definitely convinced that synchronous IPC is the right choice.
(But: there some of you who are not as much convinced as I am. Well, well. :-)
In my opinion, using very lightweight processes (threads) will give us the
possibility to provide *asynchronous* IPC outside the kernel.

I think, both IPC versions can be used with the following interface, namely

	send, receive, reply

If we can build the IPC primitives within an object, it should be possible,
to create two (2!) kernels: one synchronous and one asynchronous. As the 
interface should be the same, there should be no problem to the application
layer and to the lower layers as well. We can then compare these two or
even offer both.

But I still want to defense my position: Asynchronous IPC will lead to an
enormous communication overhead. There's buffer management, and still the
synchronization problem, when all buffers are in use. I don't want to see
this overhead within a new OS-kernel. Note, that this overhead leads to a
performance lost. If we really want to create a fast system, we should
provide synchronous IPC within the kernel and offer asynchronous IPC as
an add-on.

David wrote:

> Well, the big problem with providing only synchronous IPC is that you
> CANNOT make asynchronous I/O out of it without having a second thread.
> The standard way in Unix to do I/O reading from two different sources
> is to make one process reading each source.  Unix now has a kludge
> called select() that allows a program to identify the descriptors with
> available I/O, but this relies on the system and process being able to
> keep up with the I/O.  On a VMS system (with asynchronous I/O), one
> queues a number of asynchronous I/O calls on each channel, and
> processes the data after it is transferred to your processes own space
> and you are notified.  I feel this is a much more satisfactory
> solution.

Actually, I think the VMS IPC is a third form of I/O, though it's
asynchronous. If I understand it right, it is possible, to direct an I/O
to write into a pre-defined data space within my own process. I suppose,
there's a call like

	receive(chan, to_memory)

where 'to_memory' points to (big enough) data space. The OS waits for data
sent on 'chan' and relay the data to the indicated data space. After a 
sender says, "End Of Send" a notification signal is transferred.

In my opinion this differs from my use of the term 'asynchronous' IPC. Here
a sender is not blocked, because data is immediately transferred into a 
system internal buffer space. On the other hand, a receiver might be blocked,
if there's no data available. (In the above case a receiver is not blocked.)
(Or am I mixing things up?)

Nevertheless, if we do agree that we can provide each form of asynchronous
IPC by an additional buffer server this VMS asynchronous method can be simply
provided: Create a buffer server, who takes such an interface, and who 
will be able to write to a process' data space. Then notification is done by
invoking a method. The easiest way would be within this method, to set a 
flag that data is ready to be used. 

Dennis is '>', David is '>>':

> Ah, I still don't believe in the kernel is where IPC should go - support
> for IPC, yes (shared memory, etc) but not the IPC itself. Maybe. I dunno.
>
>> If IPC is not in the kernel, how do you communicate with the IPC?

Nice answer. (I still want to see the chance to distribute Moose over several
machines. Then their must be mechanisms within the kernel to communicate
to the outside of a machine ... BTW: then each machine should use its own
memory, leading to distributed memory. Virtual shared memory with several 
machines isn't useful ... (s. discussion in comp.os.research)).

I have to go now, stay tuned for more PEM News,

Peter