Re: L4Mach or Refactor Hurd Servers?

[Niels Möller]

Ian Duggan <address@hidden> writes:

> It's possible to do an IPC receive with a timeout (possibly indefinite)
> with L4. It should be possible to mimic the described behavior using
> this, no?

If I have understood select on the Hurd correctly, this is the rpc
that is used (from hurd/io.defs):

/* SELECT_TYPE is the bitwise OR of SELECT_READ, SELECT_WRITE, and SELECT_URG.
   Block until one of the indicated types of i/o can be done "quickly", and
   return the types that are then available.  ID_TAG is returned as passed; it
   is just for the convenience of the user in matching up reply messages with
   specific requests sent.  */
/* INTR */
routine io_select (
        io_object: io_t;
#if defined (REPLY_PORTS) || defined (IO_SELECT_REPLY_PORT)
        replyport reply: sreply_port_t;
#else
        ureplyport reply: mach_port_make_send_t;
#endif
        waittime timeout: natural_t;
        inout select_type: int);

Note that the rpc blocks. With syncronous L4-style rpc, each thread
can have at most one L4 rpc in progress. So if select is converted to an
syncronous rpc (i.e. one L4-style rpc, no separate select and
select-reply messages), you'll need one thread for each fd, and that's
no good, I think.

I hope there's a natural L4 way to do "wait for the first out of n
events", and that is what should be used for select. I don't know
what, but figuring that out is important when designing the libports
implementation on L4.

I guess one needs a to first send an L4 rpc to each server to start
the select operation, and then issue a single L4 receive call that can
get the reply from any of the servers (and finally, perhaps cancel the
operations we're no longer interested in).

My apologies if all this is obvious to everybody but me.

> > BTW, how hard is it to implement something like Solaris "doors" on L4?
> > If reconsidering the RPC-semantics, that might be an alternative worth
> > investigating.
> 
> I'm unfamiliar with Doors. I found a few pages about an old "Doors on
> Linux" implementation that was abandoned for "general lack of interest".
> Where could I find more info on this?

I'm not terribly familiar with it either, and it was a little hard to
dig up references. Appearantly, the keyword is "Spring", not
"Solaris". I found an overview of Spring
http://java.sun.com/people/kgh/spring, including an introduction to
doors, and some further references. I quote it below:

: 5.1 Doors
: 
: Doors are pieces of protected nucleus state. Each domain has a table
: of the doors to which it has access. A domain refers to doors using
: door identifiers, which are mapped through the domains door table
: into actual doors. A given door may be referenced by several different
: door identifi-ers in several different domains.
: 
: Possession of a valid door gives the possessor the right to send an
: invocation request to the given door.
: 
: A valid door can only be obtained with the consent of the target
: domain or with the consent of someone who already has a door
: identifier for the same door.
: 
: As far as the target domain is concerned, all invocations on a given
: door are equivalent. It is only aware that the invoker has somehow
: acquired an appropriate door identi-fier. It does not know who the
: invoker is or which door identifier they have used.
: 
: 5.2 Object Invocation Via Doors
: 
: Using doors, Spring provides a highly efficient mechanism for
: cross-address-space object invocation. A thread in one address space
: can issue a door invocation for an object in another address space.
: The nucleus allocates a server thread in the target address space and
: quickly transfers control to that thread, passing it information
: associated with the door plus the argument data passed by the calling
: thread.
: 
: When the called thread wishes to return, the nucleus deactivates the
: calling thread and reactivates the caller thread, passing it any
: return data specified by the called thread.
: 
: For a call with minimal arguments, Spring can execute a low-level
: cross-address-space door call in 11 ms on a SPARCstation 2, which is
: significantly faster than using more general purpose inter-process
: communication mechanisms [1].
: 
: Doors can be passed as arguments or results of calls. The
: nucleus will create appropriate door table entries for the
: given doors in the recipients door table and give the recipient
: door identifiers for them.

It seems a little similar to Mach ports (not surprising), but
syncronous (like L4), and with some automagic thread-juggling, which
seems to be the novel part of it. There's a flag DOOR_UNREF that can
be passed to door_create, that looks like (from the door_create(3X)
man page) it requests a no-senders notification.

Regards,
/Niels