Re: libports on L4

[Ad Buijsen]

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.

> 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.  

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.  

Stepping back from mach/Hurd a bit: the standard L4 client-server IPC
will work when one server thread has more than one client.  If the load
on that one thread gets too high, we simply spawn a few more.  Some
sort of load balancing may be nice.  Authentication can be done using
L4's thread IDs (have to look at deceiving IPC for problems and
opportunities).

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


> I've cc-ed this to address@hidden Please see
>   http://mail.gnu.org/mailman/listinfo/l4-hurd
> to subscribe.
The confirmation of subscription will be sent at the same time as this
message; talk about races!


    Ad Buijsen