35704 - Grateful shutdown

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P3)

Description

[Ben Bucksch (:BenB)]

Mailnews needs to do some actions on shutdown (specifically emptying the trash).
Of course, they shouzld also be performed, of the app is closed via the window
manager.

- Additional Comments From [e-mail] 2000-04-05 19:08 in bug 16244 -
As I understand it, Jeff is running this url as the app is exiting. Highly 
unlikely that it gets to run

Please refer for more details (which I don't fully understand) to comments to
bug 16244.

Empty trash on exit is a n important feature for mailnews. beta2.

Comment 1

[Suresh Duddi (gone)]

Jeff and I talked about how he could do this before shutdown. Close mail window 
should be handlable by mailnew team itself. Reassigning to jeff.

Comment 2

[Karen Huang]

Shouldn't this bug log for MailNews? 
(Should "Product" entry field choose MailNews?)

Comment 3

[jefft]

Playing trick upon receiving "xpcom-shutdown" notification doesn't help me. It 
seems a little bit too late as one of my fooling around test shows. What I did 
was to wait on a monitor after kicking of imap empty trash request. When imap 
empty trash finished on an imap thread, it shall notify the monitor of 
completion. In theory this should work but it didn't.

Comment 4

[Suresh Duddi (gone)]

If thats the case, then you should work on close-window notifcation (if there is
one). What else. I dont think xpcom can help here. This is at a higher level
than xpcom.

Comment 5

[Chris Waterson]

I'm not exactly sure what the problem is here. Is it that there's no place to
put "shutdown" code? Or is it that you need to do a bunch of asynchronous work
while shutdown is going on?

If it's the former, then you could try

- bill law's appshell componentry, if that still exists
- using an "onunload" handler in the mailnews window (this may be too eager, as
it would run whenever the mailnews 3pane was closed)
- some TBD mechanism in XPCOM

If it's the latter, then it seems like we need a way to keep the main
application event loop alive until everyone agrees that it can die. Sounds like
trickery required in XPCOM or appshell to make that happen.

Comment 6

[jefft]

It's the latter case.

Comment 7

[Suresh Duddi (gone)]

Can someone verbalize what kind of notification is required. The xpcom-shutdown
notification happens when NS_ShutdownXPCOM() is called *before* any service is
destroyed and dll unloading begins. This is the earliest xpcom can give this.

Comment 8

[jefft]

Okay, let me try ....

xpcom-shutdow is a kind of notification to the world saying that we are done 
with the app go do some clean up if you need to. Components then notify their 
subcomponents or their child threads to kill themself. If one of the child 
thread or subcomponent says wait don't kill the app yet I still need to do some  
asynchronous operation (which rely on other components and the other components 
have been told to shutdown). It would be too late because of other components 
have done some clean up work. This is basically what's the problem we are facing 
here. What we need to solve is a mechanism prior to the shutdown to inform all 
parties that need to do the pre-shutdown work go do their work and then report 
back that they have done their tasks. Once all parties have done their work 
and reported back we can then proceed the shutdown. 

Comment 9

[Warren Harris]

I see. Seems like the appshell needs a mechanism where interested parties can 
register to be notified for when it wants to go away, and then when shutdown 
occurs, they get notified, do their cleanup, and then release the appshell when 
they get the last event they want.

Seems like this belongs in Travis' xpcom/appshell stuff that he never finished, 
and then the xpfe appshell needs to use it. Cc'ing Brendan.

Comment 10

[Phil Peterson]

[nsbeta2+]

Comment 11

[jefft]

dp, here is one proposal -

If we could have a service in components manager to allow components register a 
pre-shutdown callback routine which returns a monitor. Then the components 
manager manager calls the callback prior to the shutdown, waits on the monitor 
returned from the callback for a maximum of wait time say 100 seconds (to 
prevent deadlock). The callback routine notify the completion to the components 
manager via the monitor. Will this work?

Comment 12

[Ben Bucksch (:BenB)]

> waits on the monitor 
> returned from the callback for a maximum of wait time say 100 seconds (to 
> prevent deadlock).

I suggest to send heatbeats. 100s are too long for a real error and may too less
of roaming.

Comment 13

[Chris Waterson]

jefft: why not have the component itself manage the monitor? You just get the 
callback ("please shut yerself down now"), and then you can block until you've 
decided that either a timeout has occurred or it's time to go away. It'll be 
*your* job to figure out how to do thread synchronization, but, it always *has* 
been, since your component was the one that fired up new threads, right?

Whatever you do, please don't make the app hang around forever like 4.x 
sometimes does. That drives me nuts! :-)

Comment 14

[Suresh Duddi (gone)]

Observers are a framework. Anyone can host an observer via the observer service.
Thus any service can notify say appshell can notify "appshell-service-shutdown"
and anyone could be observing this. XPCOM provides the framework but doesn't
need to involved at all. What do you think ?

And I dont know about blocking. That is such an app specific thing. If you
choose to block in your observer->Notify() routine and understand consequences,
then great. As waterson says, dont make the app hang around for too long.

Comment 15

[Warren Harris]

Unless I'm missing the point, I thought the issue here was keeping the event 
loop active until every client has decided their asyncronous stuff has been 
completed. Wait/notify is the wrong model. Right now we're dropping out of the 
event loop prematurely -- we need to keep going around the loop until every 
client has agreed they're ok with quitting (by decrementing a count).

Cc'ing Rick Potts since I think he's thinking about event loop stuff (or should 
be).

Comment 16

[jefft]

I have found a way to fix this. Thanks for everyone's help.

Comment 17

[Warren Harris]

Do tell (before I have someone go off and fix the event loop).

Comment 18

[jefft]

Warren, thanks for helping. It turns out that the event queue is still intack 
and working by the the time that components manager send out the xp-shutdown 
notification. As dp and waterson have suggested that letting the component 
itself managing it's own monitor. I ended up with using PR_CMonitorEnter(), 
PR_CMonitorExit(), PR_CWait(), ProcessingPendingEvents() and along with the 
nsIUrlListener interface I managed to have the empty trash on exit feature 
implemented and working. See bug 16244 for details. Thanks much for offering the 
help. Appreciated.

Comment 19

[Karen Huang]

By uisng WinNT 05-22-09-M16 commercial build 
Linux 05-22-08-M16 commercial build 
Mac 05-22-08-M16 commercial build 
Empty Trash on Exit is working now.
Marking as verified.