l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: emulating no-senders notifications in L4?


From: Espen Skoglund
Subject: Re: Re: emulating no-senders notifications in L4?
Date: Wed, 2 Jan 2002 01:45:14 +0100

[Ondrej Hurt]
>>> The application has the right to trash itself but it should not
>>> harm the rest of the system. In the case of unreliable fault
>>> detection, it is not only the app who will suffer because it can
>>> lock resources in other apps, it can hold references to misc stuff
>>> forbiding its deletion (leaving it 'busy'), it consumes task slot
>>> etc.

>>> BUT - I realized that the possibility of exception handler making
>>> another exception making another exception making another
>>> exception ...... is standard in UNIX and we must do it the same
>>> way :-/

> And I suppose that this would happen on L4:

> 1) you set up an exception handler
> 2) some thread causes exception which is IPCed to the handler
> 3) the handler thread receives the IPC 
> 4) the handler causes some exception (not pg fault) itself
> 5) exception is IPCed to the handler again ... but it will not
> receive it because it is already being blocked by this exception

> So the desired(?) "exception looping" will not take place, unless
> you set another thread as exception handler at the beginning of the
> original exception handler. Or am I missing something as usual ? :)

Not quite right.  If the handler thread raises an exception in step 4
the exception will be sent to the exception handler thread of the
exception handler.  Putting yourself as the exception handler is
certainly not a good idea, and step 5 will therefore not happen.

What *could* happen was that the exception handler in step 4
redirected the execution of the faulting thread to some exception
handling routine.  The exception handling routing could then raise
another fault (in the context of the originally faulting thread) and
this exception would be sent to the exception handler thread.  Since
the handler thread already has handled the previous exception, i.e.,
redirected the execution of the faulting thread, it will be ready to
receive the next exception.  This enables the system to generate a
loop of exceptions.

        eSk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]