[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libports on L4
Re: libports on L4
Mon, 6 Nov 2000 14:12:02 +0100
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 J. Verbruggen, address@hidden, Daneel on IRC,
room A5005 science faculty KUN, phone: +31-24-3652229