Re: Research using L4Hurd

[Neal H. Walfield]

> I may well be confused, but I don't think I'm confused in that
> particular way. I was thinking about the server side of the
> i/o-interfaces. My impression is that most Hurd file servers call
> fshelp_manage_multithread which starts a new thread for each open.

After each open, the port is added to a port bucket which is managed
by either ports_manage_port_operations_multithread or
ports_manage_port_operations_one_thread.

> > I think you are confused about L4 ipc.  Although the ipc is
> > synchronous, rpc do not have to be.
> 
> What's the difference between ipc and rpc here? In the hurd, it seems
> the terms are used interchangably, and there's currently no truly
> *remote* procedure calls. One proposed terminology is to say that
> "ipc" is the microkernel communications primitive, and "rpc" is a
> combination of one or more ipcs that correspond to one operation as
> defined in some foo.defs file.

Sure, there are generally two ipcs per rpc, the send and the receive
phase.

> > Which is to say, when the client sends an ipc to a server, it blocks
> > until either the supplied timeout is reach or the server does a
> > receive.
> 
> When I said "unnatural", I was thinking of the restriction that each
> thread can have at most one outstanding ipc call, i.e. a call that is
> waiting for a server to receive it. Is that correct?

In Mach, Mach proxies and buffers the requests so that you do not have
to wait for the server to do a receive.

> To have several outstanding rcp calls (per the above definition), the
> rpc must consist of two separate ipc:s, representing call and return.
> My impression have been that one goal is that most Hurd rpc calls
> should correspond to a single L4 ipc (with some exceptions like
> io_select), but I don't know if that's possible/practical.

Most will correspond to two L4 ipcs just like they correspond to two
rpcs in Mach.