[coyotos-dev] Status and roadmap

[Sam Mason]

On Mon, Jan 22, 2007 at 10:22:30AM -0500, Jonathan S. Shapiro wrote:
> On Mon, 2007-01-22 at 12:03 +0000, Sam Mason wrote:
> > On Fri, Jan 19, 2007 at 01:31:04PM -0500, Jonathan S. Shapiro wrote:
> > > On Fri, 2007-01-19 at 16:27 +0000, Sam Mason wrote:
> > > > What happens if a process has designated itself as its exception handler
> > > > and faults in a non-activated state, then subsequently faults in the
> > > > activated state while handling the non-activated fault.
> > > 
> > > Doesn't matter how it got to the activated state. Since it is already in
> > > the activated state, it will not receive the message until it exits the
> > > activated state, which it cannot do because it has ceased to execute
> > > instructions pending resolution of the execution exception.
> > > 
> > > So: the process ceases to execute instructions.
> > 
> > Otherwise known as a dead-lock, or would something intervene and kill
> > off the process?  I guess in this case the kernel would be able to
> > realise, but the general case seems to complicated for me.
> 
> A third-party process, notably a debugger, can intervene here by
> changing the fault handler capability. At that point the fault will be
> delivered to the new handler.

OK, but at this point we're probably in the domain of a real user.

> The kernel does not kill processes. The process in question is not using
> kernel resource in any case, and can be paged out. Reclaiming the
> process is the job of application-level code. In this case, the most
> likely method will be to destroy the space bank, because the process
> cannot respond to a "destroy yourself" request.

I'm still getting used to a such a minimal kernel!  I also keep getting
the feeling that there should be some way of knowing that this has
happened and we should be able to recover from it.  But this is just one
of many possible failure modes and once a process has got itself into
this state I guess there's not much that can be done for it.


  Sam