Re: Comparing "copy" and "map/unmap"

[Jonathan S. Shapiro]

On Tue, 2005-10-11 at 01:15 +0200, Matthieu Lemerre wrote:

> We want to be able to abort any blocking operation and this seemed to
> be quite complex to manage in a server.  So Marcus came with the idea
> of a notification server: instead of sending a message to the server
> to tell it to abort the RPC, we could just have the thread stop
> waiting for the notification server.  The server wouldn't even notice.

First question: who is "we"? If the client has paid for its resource,
and wishes to block forever, it is none of the kernel's business (or the
operating system). Of course, we must be able to destroy the storage
when the owner wants it back, but this is a separate issue.

However, I think the case you mean is that the client wants a watchdog
timer. Let me first explain why this is a very very bad idea, and then I
will explain how to do it.

In practice, there are only four types of watchdog timer values:

  1. Don't wait.
  2. Wait forever.
  3. Wait for some amount of wall clock time that is based on
     a physical device specification -- e.g. an expected bound on
     seek delay.
  4. Wait for some amount that some developer believes is "long enough"

Cases 1 and 2 are sensible. Case 1 is *required* whenever you send a
message to a less-trusted receiver (because otherwise the sender could
be blocked). Case 3 is very important but very very rare. We have
concluded that it is too rare to justify kernel support. Case 4 has the
property that all uses of it are ad hoc and therefore wrong. The *real*
reason to remove kernel support for case 3 is that it makes case 4 hard
to do.

BTW, the L4sec team seems to agree. The last time I looked they were
removing IPC timeouts other than FOREVER and DONTWAIT.

Okay, how about the watchdog timer?

We think that the right way to do this is with a debugger thread that
reaches in using the process capability and changes your process state.
It is mildly tricky, but it can be done in a library routine without
difficulty. It is also awkward enough to discourage misuse.


> >> So when the client is done with a server, it could revoke the
> >> capability it gave to it to give it to another server.  By doing so,
> >> it ensures that there is always only one sender of a message to a
> >> message box.
> >
> > If you need one sender and you potentially have many, it sounds like a
> > queueing mistake somewhere, but I would like to wait until I understand
> > the messaging server protocol better.
> >
> 
> In the notification server I descirbe, you allocate some space for the
> message, and the notification server gives you back a capability to
> send messages in the allocated space.  It's then up to you to give the
> capability to only one server at a time.
> 
> Revoking a capability from a server is only a way not to allocate new
> space on the notification buffer, but re-use an older space.

There are several objects in EROS that do things similar to what you
describe. One (distantly) related object is the mutex object:

http://www.eros-os.org/devel/ObRef/standard/Mutex.html

In the source tree (but not in the documents, regrettably), there is an
object called an "event queue" that does what you want but only permits
single word messages. The message length could easily be extended. The
source code can be seen at:

http://www.opencm.org/opencm/~/PUBLIC/EROS/DEV/eros//784/src/base/domain/evtqueue/evtqueue.c

You might also want to look at the docs for the "buffered stream"
object:

http://www.eros-os.org/devel/ObRef/standard/BufStream.html


But I think that you have a protocol error here. The storage for the
buffer must not come from the server if the server is shared -- even if
it is bounded, there is a denial of resource attack.

shap