[interfacekit] Re: Shutdown Process

[moved the thread from the commit list to this one]

On 2005-07-06 at 16:24:30 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > Until this, maybe apps with background app flag could be shutdown
> > > in
> > > parallel (should be most of system apps), but serialize the user
> > > apps shutdown?
> > I don't think, it's safe to assume, that a background app would never
> > want to
> > display an alert on shutdown. E.g. imagine a scheduler type daemon
> > app that
> > shall not appear in the Deskbar, but might want to display a reminder
> > on
> > shutdown.
> 
> Well, it appears to be a rare enough occassion to be neglected - ie. in
> that case, two alerts at the same time might be acceptable, after all,
> there would need to be two of those apps, then :)

OK, you have a point there.

So the shutdown process would work like this:

1) Terminate non-background user applications one after the other.

2) Terminate non-background system applications one after the other. This 
would basically be Deskbar and Tracker (ATM I just mark all that live in 
the /boot/beos/system (except the servers) as system app). This is the 
point of no return; i.e. when starting this phase, the "Cancel Shutdown" 
button is being disabled and apps requesting cancelation will be 
assassinated viciously.

3) Broadcast shutdown request to all background apps (save the vital 
servers (app, input, registrar)) and wait until they're gone (starting to 
kill them after a timeout).

4) Send SIGHUP and shortly after SIGKILL to all remaining processes (save 
the vital servers).

5) _kern_shutdown()

6) When 5) fails -- could only possibly happen in case of power off, if I'm 
not mistaken -- show the "Reboot System" button and wait for the user to 
press it to issue a _kern_shutdown(true).

> But anyway, I tested the shutdown process on R5, and have a few
> comments:
> - <test>shutdown does not return

Is it supposed to? It uses BRoster::Shutdown() which I implemented only to 
return when an application or the user cancelled the shutdown or an error 
occurred. I actually don't see that much point in returning immediately, 
for 1) you won't know when the shutdown fails, and 2) it is undefined how 
long the process will continue to live after requesting the shutdown.

> - the window is always just centered on screen, and doesn't remember
> its last position (possibly an acceptable regression, though) :-)

Oh, the position of the shutdown window is stored?! Bummer! :-)

> - I tested with "People", and it was killed after a few seconds, ie. I
> did not have much time to answer its alert

Yep, R5 suspends the shutdown with a message that the application may be 
blocked on a modal panel. I would want to do that too, but need a support 
function that provides this info.

> - maybe the shutdown requester should stay open for a few seconds if an
> application aborted the process with a message like "BeHappy aborted
> the shutdown process"

Sounds like a good idea. Will do that.

> - it's way too fast, how am I supposed to test this? ;-))

Now that I moved to the one by one strategy it's already considerable 
slower. :-P

CU, Ingo

Other related posts: