Re: libports on L4

[Erik Verbruggen]

On Sun, Nov 05, 2000 at 05:03:13PM +0100, Ad Buijsen wrote:
> On  4 Nov, Farid Hajji wrote:
> 
> > Do we really want to pay for the overhead of multiplexing and
> > demultiplexing each message at the libports level? It may be
> > a quick way to port libports to l4, but then, we won't be able
> > to use short messages and other quick L4 IPC mechanisms. I'm not
> > sure what the best way to proceed should be right now.
> 
> Neither am I, to be perfectly honest.  At the moment I am ploughing
> through the docs on the Hurd and mach.  Once I have the idea
> (illusion?) that I have a sufficient grasp on things, I will get stuck
> into libports and see what I can make of it.

One way you could optimize is to see if a long message (which is also
fast on L4 as it has to be page-aligned) can be put or allocated in a
(new) page. Hurd and GNUMach use MIG for multiplexing and stuff, so it
might be possible to put this in there. Disclaimer: I haven't looked at
this very much. The ports are definitly something we want to support (I
think), as Hurd uses it to see if someone is allowed to communicate. I
think this might be implemented using the thread hierarchy of L4 and
putting it in the clan thread.

> > I understand why you want to dedicate a thread per task for communications:
> > 
> > For an IPC to succeed, one thread must ipc_send and one must already
> > ipc_receive synchronouusly. Receiving threads are easy: they just sit
> > listening on an ipc_receive call and once waken up, demultiplex/dispatch
> > the incoming message. Sending threads could wait on an ipc_receive() for
> > notifications on their own side and, once woken up, send outgoing messages.
> > 
> > The problem here is that the sender thread can only listen for notifications
> > when not ipc_send()-ing outgoing messages. Threads on the sender's side
> > wishing to notify the sender thread would fail to do so, because the
> > sender thread is not ipc_receive()ing right now. Do we need two threads
> > on the sending side (one to wait for notifications and one for handling
> > the sending proper) or do we need pthreads and condition variables here?
> 
> The textbook client-server interaction; it breaks in the case of
> multiplexed connections because the needed "correspondence-of-states"
> of the communicators cannot be guaranteed.  It will be necessary to
> split the communicator (or should I call it proxy?) into two threads,
> one for sending and one for receiving.  

Mach hasn't got the notice of a clan-leader, so we might be able to use
that tread as the "proxy" for the messages/ports.

> If we were to follow the present implementation of the Hurd, we would
> have to start a separate thread for each port; a fileserver would be in
> severe danger of overflooding the thread space.  

It already is. If you have Hurd running, do a "ps -AT" and you'll see
that the ext2fs server does have quite some threads. We *do* want to
multiplex more [cp]threads onto one L4 thread, as 128 already is far too
little. It's not only the thread-per-port, if I recall correctly you can
tell Mach or the ports to spawn a thread with each incomming message (!).

> Am I making sense or have I gone totally off the track here?

No, not at all as you can see.

Erik.
-- 
Erik J. Verbruggen, address@hidden, Daneel on IRC,
room A5005 science faculty KUN, phone: +31-24-3652229