resume capabilities

[Kragen Sitaker]

Bill Frantz writes:
> At 11:43 AM 12/30/1999 -0500, Kragen Sitaker wrote:
> >Does this mean I must trust every process I communicate bidirectionally
> >with not to let me hang forever?
> 
> This problem is not unique to EROS-like systems.  As far as I know, an
> analog exists in all programming systems.  In general you can divide the
> things you call into three categories:
> 
>   (1) Ones you trust not to hang you.
>   (2) Ones you don't trust, but must depend on anyway
>   (3) Ones that may hang you.
> 
> In case 1, you don't have a problem.  How you gain the necessary trust is a
> difficult problem.  In the KeyKOS manual, we attempted to document the
> behavior of objects which could be trusted by describing them as "prompt".
> Of course, programs don't always behave according to their specifications.
> :-)

OK, let's look at a hypothetical example --- a process of an
Apache-like web server.  Each Apache child does the following:

1. sits and waits for a connection to come in; 
2. when a connection comes in, one of the children awakes, 
3. reads data from the connection, 
4. creates a response and sends it back, 
5. closes the connection, and
6. goes back to waiting.

Presumably in steps 1, 2, 3, 5, and 6, the web server is blocked
waiting for the networking code to resume it.

In step 4, it might do a number of things.  For example, it might
spawn off a CGI script belonging to a user, or it might read from a
file belonging to a user.

In this case, the web server doesn't trust the CGI script (or possibly
even the parts of the filesystem belonging to users); if it takes too
long to return, the web server will want to send an error to the client
so the client doesn't think your web server is poorly administered.
Worse, all your web server processes will eventually end up hung;
eventually you won't be able to start any more.

Assuming that the filesystem's interface is designed under the
assumption that filesystem domains will be invoked with call, not send
or return, how would you handle this?  Can you do a send and make it
look like a call?  You could spawn a little domain that would accept
your call and the resume key, hand the resume key to another domain
that will invoke it after a timeout, and then do the filesystem or CGI
call you wanted in the first place.  (Is there a better way to handle
this?)

> >Maybe it's premature to be worrying about stuff like this when the OS
> >doesn't run Emacs yet.
> 
> This kind of trust is so basic, I think you have to consider it from the
> very beginning.

I think you are right; that was why I bothered to post.

(I was thinking about the lack of software interrupts, like Unix
signals, which are (a) impossible to emulate efficiently by any other
means and (b) relatively easy to add to the kernel later if people
think they're a good idea.  Obviously the KeyKOS people don't; Windows
NT people didn't, either, which is why interrupting a Windows NT
process stuck in a compute loop causes dialog boxes to pop up and then
kills the process without notifying it.  There is much to be said for
the idea that signals enabled Unix programs to get away with all kinds
of brain-damage, though. . .)

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>