libports on L4

[Farid Hajji]

Thu, 2 Nov 2000 18:13:58 +0100 (CET), Ad Buijsen <address@hidden> wrote: 
> Ports, as I see them, are simply channels for communication between
> processes.  They are identified by their ID (what else?) and protected
> on both sides by their associated rights (at least, in mach).
> 
> A naieve way to implement this on L4 would be to give each task a
> thread that handles all communication for its worker threads.  The
> latter write to (or read from) ports that are presented to them by their
> "communicator", which transforms the messages into "proper" L4 IPC
> messages, putting the port ID into the first element of the payload. 
> The receiving communicator unpacks the L4 payload and examines the port
> ID to decide what to do with the port payload - mostly it will queue
> the message for one of the worker threads in its task.  Note that the
> communication between worker and communicator can be as asynchronous as
> you want, and that the "port" ID is also used for authentication.
Putting ports messages (the ports protocol?) in the payload of an
L4 message is what I've meant with "opaque" message.

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.

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?

> This scenario is almost certainly far too simple; I would be happy to
> discuss this further in a more suitable list.  If one has already been
> decided on, please tell me where and how to subscribe.
I've cc-ed this to address@hidden Please see
  http://mail.gnu.org/mailman/listinfo/l4-hurd
to subscribe.

>  Ad Buijsen

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.