Microkernel IPC

[mudi]

I'm trying to develope a microkernel,and wonder
how should I handle the following:

A driver (ring1) sends a message to a server(ring2)
and waits on reply(no message buffering),but what happens if the server never replies(faulty)
That would freeze the driver too !
How can I work this around ?

[J. Weeks]

>On 2001-07-29 18:11:28, mudi wrote:
>I'm trying to develope a microkernel,and wonder
>how should I handle the following:
>
>A driver (ring1) sends a message to a server(ring2)
>and waits on reply(no message buffering),but what happens if the server never replies(faulty)
>That would freeze the driver too !
>How can I work this around ?

As far as I know, most operating systems don't...
the driver hangs, and the user is responsible for
removing it from memory.

I'm sure some people put a time delay in there...
if the server doesn't respond withen 2 or 3 seconds
the request is sent again, or the driver fails with
a message.

Ideally, the server isn't faulty If it is, the
programmer realizes this, and produces a bugfix
withen hours

J. Weeks

>

[mudi]

>On 2001-07-29 20:36:15, J. Weeks wrote:
>>On 2001-07-29 18:11:28, mudi wrote:
>>I'm trying to develope a microkernel,and wonder
>>how should I handle the following:
>>
>>A driver (ring1) sends a message to a server(ring2)
>>and waits on reply(no message buffering),but what happens if the server never replies(faulty)
>>That would freeze the driver too !
>>How can I work this around ?
>
>As far as I know, most operating systems don't...
>the driver hangs, and the user is responsible for
>removing it from memory.
>
>I'm sure some people put a time delay in there...
>if the server doesn't respond withen 2 or 3 seconds
>the request is sent again, or the driver fails with
>a message.
>
>Ideally, the server isn't faulty If it is, the
>programmer realizes this, and produces a bugfix
>withen hours
>
>J. Weeks
>
>>

Ok,let's go a little "downer" what if the same happens
between an "app" and a "server",I try to never
expect the ideal case(my os's point is modularity and stability and simplicity in code).
I think counting on timeout woudl be too expensive !