Re: Getting Started with Hurd-L4

[Marcus Brinkmann]

At Tue, 26 Oct 2004 13:10:41 +0100,
Sam Mason <address@hidden> wrote:
> 
> Marcus Brinkmann wrote:
> >Sam Mason <address@hidden> wrote:
> >You mean using the same container in several parallel RPCs?  I think
> >that way lies madness.
> 
> I think I was assuming something like scheduler activations (I
> think something like this is going to be kind of essential) would
> be running in this system and this would allow several operations
> to be combined into a single request that would finally get pushed
> out to the serving task when enough have been accumulated (generally
> when the task's time slice runs out).

No, this can't work at all.  Our RPC model is pretty simple, and
synchronous.  The sender will block until the message is received (and
in fact, the sender remains blocked until the reply is sent and
received).  You need one thread per pending RPC.

Now, in a very complex model, you could theoretically not send an RPC
directly, but record it somewhere, and then send a "combined RPC".  I
don't see what that would do for you.  RPCs should not occur often.
If you do many, many RPCs, you are doing something fundamentally wrong
and should look for something else (like shared memory protocols).

> >However, we could indicate for each operation
> >which window in the container to use for that operation... not sure if
> >this will always work well, but there are things you theoretically
> >could do here, I think.  Not sure it is really worth it.  I'd just use
> >one container per mapped file, I think (if I were to reuse them).
> 
> Again, I'm not sure if this sort of thing is at all relevant to L4 at
> all.  When I've been thinking about these sorts of things before, I've
> always been trying to reduce the amount of IPC to an absolute minimum
> but haven't based any of this on any empirical testing.

It's ok to optimize things a bit (like, for select(), you don't want
one RPC for each file descriptor, but one RPC for each server
providing files among the descriptor set).  But let's not be
overzealous, certainly not before having actual benchmarks.

Thanks,
Marcus