Re: synchronous RPCs vs. asynchronous RPCs

[Marcus Brinkmann]

On Fri, Sep 05, 2003 at 02:33:42PM +0200, Niels M?ller wrote:
> I don't know about msync, for I care about poll. I think it is
> important to be able to poll/select on thousands of objects, without
> using thousands of threads.

As long as the thousands of objects are not provided by thousands of
different servers, there is no problem.  Even in my synchronous model you
would only use on thread per server, and combine all objects in a single
RPC.

> One way of doing poll may be as follows, where the main point is that
> a single thread receives notifications form multiple servers.

[protocol details snipped]

This is one way to do a notification based select()/poll(), and is in fact
close to how select()/poll() is implemented now.  It saves on the number of
threads with the additional cost of the short poll after you get the first
notification (which also has to serve as a cancellation of the previous
notification request, or you have to make another abort operation).

The reason I am trying to avoid such solutions is their complexness, both
user and server side.  But they might provide a good optimization, in
particular if you do:

> Sending rpc:s to all the servers seems a little expensive, it may be
> possible to poll on n file descriptors with fewer than O(n) rpc calls
> on average, like this: We spawn R, and ask all the servers to always
> notify R when i/o becomes possible (regardless if we're blocking in
> poll at that moment). R will get most of these notifications and keep
> state.

But they also suck in a requirement to take care of DoS attacks in a special
way, and I have not found any satisfactory policy for that.

> Does that make sense? Or do you have some completely different plans
> for poll?

It makes sense, and is very close to one of the options I have pondered for
quite a while.

> One should use similar mechanisms for all of poll, file and directory
> notifications, waitpid, and the pthread function to wait for
> particular signals (don't remember the name), so that one can use a
> *single* hurd operation to wait for i/o on fd 7, changes to the directory
> /bar, death of process 17, or SIGWINCH, whichever occurs first.

Well, this is very dandy, but now you must really not any longer duck the
question but tell us how notifications are implemented in the server side.

> I think one can aim for a design with *one* notification protocol (ok,
> perhaps two, if task death notifications are special enough to have
> its own protocol), and make everything else syncronous.

So much we knew already.  One notification protocol does not exist so far.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/