At 02:57 PM 12/30/1999 -0500, Kragen Sitaker wrote:
>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?)
There may be a better way depending on the details of the system, but this pattern is the most general. You might want to apply the pattern to the whole Apache child, covering errors in the child as well as in the things it calls.
>
>> >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. . .)
Unix style signals can be implemented in EROS style systems. They do cost more than in a Unix style system. For timing out calls like in our Apache example, if we can keep the cost on the "notice signal and act" path, then the extra cost won't matter because timeouts are so rare.
Bill Frantz "Home pages are passe', everybody's Communities.com building a palace" - Time Magazine Capability Security Guru www.thepalace.com, www.onlive.com frantz@communities.com www.communities.com