Re: L4Mach or Refactor Hurd Servers?

[Espen Skoglund]

[Niels Möller]
> Farid Hajji <address@hidden> writes:
>>> So I think it wuld be said to throw away the support for that
>>> entirely, but there may well be some nice way to do it on the library
>>> level (in the client's process) by using a syncronous RPC-interface
>>> and some extra threads.
>> Yes, that is the obvious hack: using a message task that is accessed
>> by libraries linked in client space. The general question is wether
>> it is necessary to use asynch IPC most of the time.

> I'm not sure you got my point: The current Hurd select rpc can't be
> used as a (single) syncronous rpc. To convert it to a syncrounos
> ipc-model like L4's, you have to butcher it up into two syncronous
> rpc:s, perhaps modelled after the file notification rpc:s,
> file_notice_changes, file_changed.

> Perhaps my terminology is a little confused. The problem is not the
> syncronicity itself, if that just means that the kernel doesn't do
> buffering. The problem is that a single rpc call is used to both
> send a request _and_ get the reply to it.

I didn't know that this was a limitation of Mach (if it really is).
Just for the information, in L4 the following (among other) types of
synchronous IPCs are supported:

  call (S) -- Send a request to S and wait for a reply from S.

  C = reply_and_wait (C) -- Send reply to C and wait for a request
              from a new C.

Did I miss something here, or is it so that Mach does not support
these kind of operations?

        eSk