Re: libports on L4

[Ad Buijsen]

On  6 Nov, Erik Verbruggen wrote:

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

The general type of mach messages consists of data words and references
to blocks of memory.  This maps one-to-one to L4's IPC, with the memory
blocks being pages.  Port rights will have to be mimicked.  I think
that a leaner and more efficient mechanism can be designed to implement
inter-server communication in a hurd-compliant way.


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

A clan's chief is a separate task; its (sole?) use is security by
acting as a censor/gatekeeper.  You can think of it as a proxy, but it
is one of a different kind.


>> 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 (!).
> 

No, it is a function in libports; mach has nothing to do with it.  

This thread thing looks like the largest hurdle to pass in getting the
Hurd running on L4.  Possible solutions are:

 -If a task T1 runs out of threads, create T2 and maps T1's address
  space to it.  The efficiency of this scheme is subject to scheduling
  behaviour and can be good if done well (I think, offhand).  The
  problem now is the depletion of the available tasks, but this is just
  a variation on the problem of mapping the Hurd's processes to L4
  tasks.  This method is mentioned in a document on L4; I forgot which
  one...

 -Multiplex user-level threads on L4-threads.  I _think_ this can be
  done as long as (L4) threads involved in _any_ sort of IPC are left
  alone; use "worker"threads only.  Again, I have not given this very
  much thought, so I may be rediculously wrong.


The following remark may be considered a heresy in this list, but there
is a school of programmers that regards this prolific use of threads as
bad design; a comment to this effect was quoted on debian-hurd
recently, and some of the regular contributors to c.o.l.d.s. wrote in
the same vein.  So, do we really need this agressive multithreadedness
to build Hurd-compiant servers?


   Ducking to avoid rude remarks and ignited Molotov cocktails,

     Ad Buijsen