Re: Persistence

[Jonathan S. Shapiro]

On Mon, 2005-10-31 at 21:26 +0100, Emmanuel Colbus wrote:
> Marcus Brinkmann wrote :
> 
> > Capabilities to resources outside of the persistent core (device
> > drivers, external filesystems, network) have to be invalidated on
> > recover.
> > 
> > This will make the applications that rely on them get a fault, which
> > they can handle by reconnecting (and then verifying their consistency
> > requirements!) or by terminating.
> > 
> 
> Yes, this may work as soon as the application tries to perform an action 
> on the given capability, but what if it was just waiting for data 
> to be available?

Coyotos is an atomic action kernel, so the only way the process can be
waiting this way is if the read() has not made any progress. When the
system restarts, the read() will be restarted, and the caller will
discover that the descriptor is now invalid.

> Is it possible for it to know 
> which of its capabilities refer to something outside the persistent 
> core?

This is an OS-level design issue. There are unambiguous rules at the
microkernel level, but the real issue here is "remoted" objects, which
are an application-level issue.

> And what if the system crashes again, but has taken his last snapshot 
> during application reconnection? (Well, such a reconnection may take a 
> long time...) Will an application who is in its recovery fault handler 
> receive the fault another time?

There is no need to deliver any further fault. The application is
already recovering, and will simply continue recovering after the second
restart.

> And what if one finds a way to deterministically crash the system, and starts
> a task which will crash it just after a snapshot? Or, worse, after twenty 
> days, just after a snapshot, and everytime it receives the system recovery
> fault, and everytime the date is set over task start time + 20 days?

Then you get to fix the kernel.

In 35+ years we haven't found a way to do this, except at certain times
when unreleased code was under active development.

shap