Closed Bug 144559 Opened 22 years ago Closed 16 years ago

Timers running during turbo shutdown

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Product:
Core Graveyard
Component:
QuickLaunch (AKA turbo mode)
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: morse, Unassigned)

References

Details

Attachments

(2 files)

list of timers that are created in our sourcecode
(deleted), text/plain
Details
list of session-logout observers that are created in our sourcecode
(deleted), text/plain
Details 
There are some timers running while we are in turbo shutdown mode.  These might 
or might not be things we want to stop, depending on such things as how often 
the timer fires and how much work it does each time it fires.  See comments in 
bug 143848 for more details

However we should be aware of which timers are still running during shutdown, 
and decide for each one whether it needs to be stopped or not.  As a start at 
determining that, I did a search for all places in which the timers are created 
and will post that list as an attachment.  Then we can look at this list, 
item-by-item, to see if these timers are stopped in turbo mode.

Another approach is to put print statements in the code that is executed each 
time a timer fires.  That way we can see if there are any timers still running 
turbo shutdown.  I tried that and observed at least two separate timers still 
firing.  I'll investigate further to determine which ones they are.  Of course 
that doesn't mean that these are the only ones -- it's just the ones that were 
initialized by the particular paths of the browser that I happened to exercise.

    
    

    
  
It might also be useful to know which of the classes that create timers do not 
handle session-logout notifications.  To determine that, I created a list of 
those places in our codebase in which session-logout observers are created.  
There are relatively few.  I'll attach that list.

    
    

    
  
My investigation revealed at least the following four timers still going off 
during turbo shutdown are:

   OnBiffTimer in nsMsgBiffManager.cpp (this is the topic of bug 143848)
   DeadConnectionCleanupCB in nsHTTPHandler.cpp
   FireTimer in nsBookmarksService.cpp
   FireTimer in nsInternetSearchService.cpp
   
Assignee: law → morse

    
    

    
  
Here are some numbers on the frequency of the four timers that I've observed 
running during turbo shutdown:

30 sec:   OnBiffTimer in nsMsgBiffManager.cpp
 6 sec:   FireTimer in nsInternetSearchService.cpp
 1.5 sec: DeadConnectionCleanupCB in nsHTTPHandler.cpp
 1.5 sec: FireTimer in nsBookmarksService.cpp

cc'ing the appropriate module owners.

    
    

    
  
DeadConnectionCleanupCB is basically a nop after session-logout.  we could
easily kill the timer for this when that notifications is sent.

    
    

    
  
correction -- I was off by a factor of ten.  The correct timer periods are:

300 sec: OnBiffTimer in nsMsgBiffManager.cpp
 60 sec: FireTimer in nsInternetSearchService.cpp
 15 sec: DeadConnectionCleanupCB in nsHTTPHandler.cpp
 15 sec: FireTimer in nsBookmarksService.cpp


    
    

    
  
Below is a list of those files that create timers.  I've also included the 
person that I think is the owner of that section of code.

Could each of you please look this over and report back whether
   a) the timer is already cancelled before entering turbo shutdown
   b) it's ok to keep this timer running during turbo shutdown
   c) we need to file a bug to have that timer cancelled

 1 sfraser         /editor/composer/src/nsInterfaceState.cpp
 2 sfraser         /editor/composer/src/nsComposerCommandsUpdater.cpp
 3 hewitt          /extensions/inspector/base/src/inSearchLoop.cpp
 4 bnesse          /extensions/pref/autoconfig/src/nsAutoConfig.cpp
 5 radha           /docshell/base/nsDocShell.cpp
 6 pinkerton       /embedding/browser/webBrowser/nsDocShellTreeOwner.cpp
 7 peterlubczynski /modules/plugin/base/src/nsPluginViewer.cpp
 8 tor             /modules/libpr0n/decoders/mng/imgContainerMNG.cpp
 9 pavlov          /modules/libpr0n/src/imgContainer.cpp
10 rangansen       /security/manager/ssl/src/nsNSSComponent.cpp
11 dougt           /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp
12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
13 rods            /content/base/src/nsDocumentViewer.cpp
14 cmanske         /content/base/src/nsSelection.cpp
15 pinkerton       /content/events/src/nsEventStateManager.cpp
16 vidur           /content/html/document/src/nsHTMLContentSink.cpp
17 jst             /dom/src/base/nsGlobalWindow.cpp
18 jst             /dom/src/base/nsJSEnvironment.cpp
19 kmcclusk        /layout/base/src/nsCaret.cpp
20 kmcclusk        /layout/html/base/src/nsPresShell.cpp
21 kmcclusk        /layout/html/base/src/nsObjectFrame.cpp
22 kmcclusk        /layout/html/base/src/nsTextFrame.cpp
23 kmcclusk        /layout/html/forms/src/nsListControlFrame.cpp
24 hewitt          /layout/xul/base/src/nsMenuFrame.cpp
25 hewitt          /layout/xul/base/src/nsMenuPopupFrame.cpp
26 hewitt          /layout/xul/base/src/nsXULTooltipListener.cpp
27 hewitt          /layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp
28 hewitt          /layout/xul/base/src/tree/src/nsTreeSelection.cpp
29 hewitt          /layout/xul/base/src/nsListBoxBodyFrame.cpp
30 hewitt          /layout/xul/base/src/nsRepeatService.cpp
31 pavlov          /view/src/nsScrollingView.cpp
32 pavlov          /webshell/tests/viewer/nsThrobber.cpp
33 blizzard        /widget/src/gtk/nsWindow.cpp
34 sfraser         /widget/src/mac/nsSound.cpp
35 pinkerton       /widget/src/cocoa/nsSound.cpp
36 pavlov          /widget/src/windows/nsAppShell.cpp
37 pavlov          /xpfe/appshell/src/nsWebShellWindow.cpp
38 tbogard         /xpfe/browser/src/nsBrowserInstance.cpp
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
40 rjc             /xpfe/components/directory/nsDirectoryViewer.cpp
41 alecf           /xpfe/components/history/src/nsGlobalHistory.cpp
42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
43 sgehani         /xpfe/components/updates/src/nsUpdateNotifier.js
44 bienvenu        /mailnews/base/search/src/nsMsgSearchSession.cpp
45 bienvenu        /mailnews/base/src/nsMsgBiffManager.cpp
46 rachum          /mailnews/base/src/nsMessengerWinIntegration.cpp
47 sspitzer        /mailnews/news/src/nsNNTPProtocol.cpp
48 sspitzer        /mailnews/news/src/nsNntpIncomingServer.cpp
49 aaronl          /accessible/src/base/nsRootAccessible.cpp


    
    

    
  
Plugin timers (nsObjectFrame.cpp and nsPluginViewer.cpp) go away with the
document and plugin so they shouldn't be around during shutdown.

    
    

    
  
the global history timer is for flushing global history to disk, so the timer
may or may not be pending during shutdown. it is ok to cancel the timer, as long
as global history is written to disk at some point (which I think is done when a
profile shuts down?)

    
    

    
  
6) embedding only, doesn't affect you
15) mac only, doesn't affect you
35) chimera only, doesn't affect you

    
    

    
  
I don't know anything about the timer code for this file:
14 cmanske         /content/base/src/nsSelection.cpp
Looks like it's a timer for autoscroll. 
Kin wrote that code.

    
    

    
  
44 /mailnews/base/search/src/nsMsgSearchSession.cpp is only used when doing a
search of local folders, so it wouldn't be active during shutdown.


    
    

    
  
This timer:

14 cmanske         /content/base/src/nsSelection.cpp

is invoked when the user clicks and drags out of the content area, to keep
auto-selection-scrolling going. The timer is killed as soon as the button goes up.



    
    

    
  
This timer:
rangansen       /security/manager/ssl/src/nsNSSComponent.cpp
is started when NSS is started up, and stopped at NSS shutdown. During turbo
shutdown, if the tray icon is kept alive, then NSS is still running and so, this
timer should be running too.

    
    

    
  
/docshell/base/nsDocShell.cpp

Docshell uses timers only to load and manage refresh urls. Timers are cancelled
when the docshell object is destroyed. There shouldn't be any timers running
after express shutdown is done. 

    
  
Blocks: 108795

    
    

    
  
None of the accessibility timers should be running during shutdown.

    
    

    
  
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   now ben         This timer is used to implement Bookmark scheduling, i.e.
                   detect when the |URL|'s contents has changed and is
                   cancelled in the Bookmark Service's destructor.

40 rjc             /xpfe/components/directory/nsDirectoryViewer.cpp
   now ???         This timer is used to work around an old issue with incoming
                   FTP data starving the UI during content creation. It
                   Its lifetime should equal that of the FTP data connection.

42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
   now sgehani     This timer is used to implement auto-updating search files
                   by checking whether an online version of the file is newer
                   and is cancelled in the search service's destructor.


    
    

    
  
> 43 sgehani         /xpfe/components/updates/src/nsUpdateNotifier.js

One-time timer that fires 5 minutes after the first window is opened
(post-profile selection).  Can go off during turbo-shutdown if the latter event
takes place before the one-time timer has had a chance to fire.  

    
    

    
  
> 4 bnesse          /extensions/pref/autoconfig/src/nsAutoConfig.cpp

This timer will only exist when Auto Configuration [netscape.cfg] is being used
(i.e. an enterprise environment). Furthermore it will only be active if the
system administrator has enabled it by using the "autoadmin.refresh_interval"
preference. The purpose of this timer is to insure that global configuration
changes are picked up by the system when it is running, insead of waiting for
the next restart. For this reason, in principal, I believe that it is valid for
this timer to continue running in turbo shutdown mode.

There is, however, a caveat. The function of this timer is to re-download the
autoconfig file from the server. This 1) assumes that necko is running, and 2)
causes network activity. For these reasons it is possible we may not want the
timer running in turbo shutdown mode.

    
    

    
  
As an addendum to the above... This is a repeating timer, the rate determined by
the system administrator. The documentation for "autoadmin.refresh_interval"
strongly recommends that care is excersised when setting this to reduce network
traffic (i.e. use a large value... the preliminary document I have shows 30
minutes as an example.) In the end the interval will be chosen by the administrator.

    
    

    
  
None of the timers that I'm aware of in the DOM code are repeating (not on a
lowlevel timer level at least), and only one of them can fire after the last
window is closed. That timer though (used for scheduling GC's), is canceled when
we get a shutdown notification. That's all that's needed from the DOM code, right?

    
    

    
  
From Blizzard:

None of these timers will happen after the last window has closed. 
There are two timers there, one for drag and drop, which is only running 
during a drag, and one for the IC window which is only around during the 
lifetime of a window.



    
    

    
  
The other timer with my name on it (biff) is the whole reason for this bug, and
is addressed in bug 143848

    
    

    
  
from darin:

see comment #6.  the nsHttpHandler timer does indeed run continuously while in 
turbo sleep mode, but it does nothing, so it isn't
really anything worth worrying about.  that said, it could be easily stopped 
when sleeping.

    
    

    
  
from vidur:

The timer in question is only scheduled when a page is loading. There should be 
no pages loading after the last window has closed, so
it should fall into the first category.

    
    

    
  
all the timers with mine name on them should be fine.

    
    

    
  
comments from kevin mcclusky (category 1 means not running after last window is 
closed)

-----

1 sfraser         /editor/composer/src/nsInterfaceState.cpp
Looks like it fits into category 1. The timer will be destroyed when the 
document is destroyed so it will not live after the last window
is shutdown.

2 sfraser         /editor/composer/src/nsComposerCommandsUpdater.cpp
Looks like it fits into category 1. The timer will be destroyed when the 
document is destroyed so it will not live after the last window
is shutdown.

19 kmcclusk       /layout/base/src/nsCaret.cpp
mjudge owns the caret code which launches the timer. Glancing at it. It looks 
like this falls into category 1. Timer used only  to blink
the caret and should be destroyed when last window goes away.

20 kmcclusk       /layout/html/base/src/nsPresShell.cpp
hyatt owns the paint suppression code which launches a timer. It looks like this 
falls into category 1. The paint suppression timer will
be destroyed when the window is destroyed.

joki owns the resize event timer. It looks like it falls into category 1. It is 
destroyed when the presshell is destroyed so it should not
exist when the last window is shutdown.

21 kmcclusk       /layout/html/base/src/nsObjectFrame.cpp
peterl owns this code. Looks like the plugin timer is destroyed if the 
ObjectFrame is destroyed so it also fits into category 1. There
shouldn't be any plugin timer if the last window is destroyed. The plugin timer 
is used to give idle time to the plugin.

22 kmcclusk       /layout/html/base/src/nsTextFrame.cpp
Looks like simon owns this. The timer is used to manage blinking text. As far as 
I know blink is not working right now. 
But it looks like it fits into category 1. The blink timer is killed when the 
last textframe with blink turned on is destroyed, so it will be
destroyed when the last window is closed.

23 kmcclusk       /layout/html/forms/src/nsListControlFrame.cpp
rods owns this. Looks like it fits into category1. When the listcontrol frame is 
destroyed the timer is destroyed so it will not live after
the window is destroyed.

    
    

    
  
24 hewitt          /layout/xul/base/src/nsMenuFrame.cpp
Safe - only active while mousing around inside an open menu popup.
25 hewitt          /layout/xul/base/src/nsMenuPopupFrame.cpp
Safe - only active while holding down a key while navigating menus.
26 hewitt          /layout/xul/base/src/nsXULTooltipListener.cpp
Safe - only active while moving the mouse around a xul document.
27 hewitt          /layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp
Safe - only active during drag operations over a tree for spring loading.
28 hewitt          /layout/xul/base/src/tree/src/nsTreeSelection.cpp
Safe - only active while holding down a key while focused on a tree.
29 hewitt          /layout/xul/base/src/nsListBoxBodyFrame.cpp
Safe - only active while holding down a key while focused on a listbox.
30 hewitt          /layout/xul/base/src/nsRepeatService.cpp
Safe - only active while holding mouse down over scrollbar buttons/track.


    
    

    
  
Addition comment from hewitt regarding 3
/extensions/inspector/base/src/inSearchLoop.cpp

   That code is in DOM Inspector and it is never used.

    
    

    
  
Most of the timers are now accounted for.  I just spoke to seth and he is going 
to respond for timers 46, 47, and 48.

I looked at the remaining other outstanding timers and concluded the following:

 8 /modules/libpr0n/decoders/mng/imgContainerMNG.cpp
   timers are for animated images and are cancelled when animation stops
   not active when in turbo mode

11 /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp
   used to see if ftp transfer times out
   might fire once after turbo shutdown if ftp transfer is in progress

34 /widget/src/mac/nsSound.cpp
   mac only -- therefore has nothing to do with turbo mode

38 /xpfe/browser/src/nsBrowserInstance.cpp
   handles async page loading
   cancelled when page is finished loading
   not active when in turbo mode

Will summarize all this shortly

    
    

    
  
I just spoke to Rangan regarding the security timer

   10 rangansen       /security/manager/ssl/src/nsNSSComponent.cpp

See his comment 15.  This is one of the few timers that will keep running in 
turbo mode, so I wanted to understand this better.  Here is what I learned.

The timer doesn't start up until the user either visits an https site or opens 
the pref panel and checks off some security preferences.  Once started, the 
timer continues running even during turbo shutdown.

The purpose of the timer is to do an automatic update of the certificate 
revocation list so that the list can be updated in the background.  The desire 
was to have this background updating continuing to occur, even after the last 
window closes and the browser enters its turbo sleep state.  Of course if turbo 
were not present the timer would stop completely between browser sessions, so 
it's not essential that the timer be kept on during turbo sleep.  But because 
turbo exists, the security people wanted to capitalize on the turbo sleep state 
to continue doing its background auto updates.


    
    

    
  
given that we have people filing bugs about us acting as a web server when they 
use personal firewalls that record this information, i expect we'll get similar 
bugs from them when we start connecting to web sites when no windows are 
closed.

if we want to do this, we should inform the user once and get their permission.

    
    

    
  
cc-ing Stephane

    
    

    
  
It seems like a bad risk/benefit tradeoff to be behaving differently like this
just because turbo happens to be running.  I'd much rather keep these cases as
simple as possible.  If stopping the timer is good enough for usual shutdown,
then it should be good enough for turbo.

    
    

    
  
>> when we start connecting to web sites when no windows are closed.

For CRLs, autoupdate happens ONLY for those CRL's which the user has explicitly
enabled for automatic update.

    
    

    
  
I've just about finished my analysis, so here are the results (modulo items 
46,47, and 48 which I'm waiting to hear from seth about).

Most of the 49 timers are specific to a function and are long since gone by the 
time we get to turbo mode.  Of those that can occur in turbo mode, I've 
classified them as follows:


ONE TIME (or only a few times) AFTER ENTERING TURBO SHUTDOWN
------------------------------------------------------------

13 /content/base/src/nsDocumentViewer.cpp (while printing in progress)
40 /xpfe/components/directory/nsDirectoryViewer.cpp (while ftp in progress)
41 /xpfe/components/history/src/nsGlobalHistory.cpp (while flushing global hist) 
43 /xpfe/components/updates/src/nsUpdateNotifier.js (5 min. after 1st window    
opened)
11 /netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp (while ftp in progress)


PERIODIC AFTER SHUTDOWN (conditional on certain things happening first)
-----------------------------------------------------------------------

 4 /extensions/pref/autoconfig/src/nsAutoConfig.cpp
   pick up autoconfig changes
   only if system admin has initiatied it
10 /security/manager/ssl/src/nsNSSComponent.cpp
   auto update the certificate revocation list
   only if https occurs or user opens pref panel

PERIODIC AFTER SHUTDOWN (unconditional)
---------------------------------------

12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
   runs but doesn't do anything.  could be easily stopped
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   implements bookmark scheduling
42 rjc             /xpfe/components/search/src/nsInternetSearchService.cpp
   implements auto-updating of search files
45 bienvenu        /mailnews/base/src/nsMsgBiffManager.cpp
   topic of bug 143848

Note that the four unconditional repeating timers are indeed the ones that I 
previously discovered experimentally (see comment 4 and comment 7)

    
    

    
  
Here's one more wrinkle in the story.  As of yesterday a new turbo model was 
checked into the trunk and will hopefully land on the branch next week.  See bug 
98673 for details).  This results in a full shutdown and process restart when 
the last window closes.  So that changes the way we need to view the above 
timers.

For one thing, the one-time timers will never get a chance to start up and so 
are completely a non-issue (there were virtually a non-issue even with the old 
turbo model since they stopped relatively quickly).  Furthermore, the 
conditional timer 10 starts up only after the user takes certain actions in the 
browser, so it will not have started up yet.  Ignoring the system-admin 
initiated timer (timer 4), that leaves just the four unconditional periodic 
timers to consider.

Of those two of them are initiated late in the browser startup cycle, after the 
leading turbo sleep terminates.  So they are not an issue.  In fact, the only 
timers left that keep going off during the leading turbo sleep are

12 darin           /netwerk/protocol/http/src/nsHttpHandler.cpp
   runs but doesn't do anything.  could be easily stopped
39 rjc             /xpfe/components/bookmarks/src/nsBookmarksService.cpp
   implements bookmark scheduling

Darin has already said that the http timer 12 is a no-op and probably should 
have been turned off before entering turbo mode.  So now I'm making a different 
statement -- it should not be turned on until after exiting the initial turbo 
sleep.  And probably the same applies to the bookmark timer 39.

I'll open separate bug reports to have those two timers started up later in the 
cycle, and keep this bug as a tracking bug on those two.

    
    

    
  
Let me just clarify the points I made in comment 38 about the new turbo model.  
The new model consists of a turbo sleep state, followed by a normal windows-open 
state followed by process terminate when last window closes.  Immediate upon the 
process termination, a new process is started which goes through the three 
states.

So the only turbo sleep state that we are now concerned about is the one 
preceding the opening of the first window.

    
  
Depends on: 146553

    
  
Depends on: 146554

    
    

    
  
I just opened the following two bug reports on the two timers that are running 
in the initial turbo sleep mode.

146553: timer 12 /netwerk/protocol/http/src/nsHttpHandler.cpp
146554: timer 39 /xpfe/components/bookmarks/src/nsBookmarksService.cpp


    
    

    
  
I just received e-mail from bbaetz confirming what I concluded about 
nsFTPProtocolHandler.cpp in comment 31.  Namely it is a one-time thing.  In 
fact, it's several one-time ticks, one for each cached server.

    
    

    
  
47 sspitzer        /mailnews/news/src/nsNNTPProtocol.cpp

this is the timer we use for when updating the subscribe dialog (when getting 
the list of news groups from the server.)  It will not unless you're doing 
that.  so not active when in turbo mode

working on the other 46 and 48 now...

    
    

    
  
46 racham          /mailnews/base/src/nsMessengerWinIntegration.cpp

this is the timer that fires to update the registry with the unread count (for 
winxp integration.)  It gets cancelled properly when "exiting" into turbo.
so not active when in turbo mode.

48 sspitzer        /mailnews/news/src/nsNntpIncomingServer.cpp

this is the timer that fires flush the newsrc to disk.  It gets cancelled 
properly when "exiting" into turbo.  so not active when in turbo mode.


    
    

    
  
reassigning
Assignee: morse → law

    
    

    
  
bug now obsolete, with the passing of "turbo"?

    
  
Assignee: law → nobody
Severity: normal → minor
QA Contact: agracebush → quicklaunch

    
    

    
  
Quicklaunch/Turbo Mode is no longer supported in Seamonkey 2 and Seamonkey1.X is in the maintenance mode (fixing only security bugs)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: