[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libports on L4
From: |
Ad Buijsen |
Subject: |
Re: libports on L4 |
Date: |
Sun, 5 Nov 2000 17:03:13 +0100 (CET) |
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
- libports on L4, Farid Hajji, 2000/11/03
- Re: libports on L4,
Ad Buijsen <=