Closed Bug 612455 Opened 14 years ago Closed 14 years ago

History.cpp should finalize statementCache on the background thread

Categories

(Toolkit :: Places, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b9
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mak, Assigned: sdwilsh)

References

Details

(Whiteboard: [fixed-in-places])

Attachments

(2 files, 1 obsolete file)

Title says it all, we could use the proxy runnable I added to Helpers.h in bug 599973
blocking2.0: --- → ?
Blocks: 599969
Correctness fix that is important, but not too important.
blocking2.0: ? → final+
Need this before we merge.
blocking2.0: final+ → betaN+
Attached patch v1.0 (obsolete) — Splinter Review
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Attachment #491225 - Flags: review?(mak77)
2 things we should figure out:

FinalizeStatementCacheProxy uses references, if we call it in destructor it's possible it will end up working on null and iirc History could do that. FaviconService shutdown is called by history thus there it's not a problem.
We probably need to build a new cache and migrate statements to it (a special copy contructor?) so we destroy an empty entity and we can finalize with all quiet.

StatementCache seem to allow asking for more statements after it has been finalized... well, is it possible we finalize the cache at places-shutdown when there is still some runnable queued up to be executed? then it would create never finalized statements. Maybe the cache should return null after it has been finalized?
(In reply to comment #4)
> FinalizeStatementCacheProxy uses references, if we call it in destructor it's
> possible it will end up working on null and iirc History could do that.
> FaviconService shutdown is called by history thus there it's not a problem.
> We probably need to build a new cache and migrate statements to it (a special
> copy contructor?) so we destroy an empty entity and we can finalize with all
> quiet.
Naw, we can just tack on strong reference to the object that owns it and we don't have to worry about it.

> StatementCache seem to allow asking for more statements after it has been
> finalized... well, is it possible we finalize the cache at places-shutdown when
> there is still some runnable queued up to be executed? then it would create
> never finalized statements. Maybe the cache should return null after it has
> been finalized?
It's not an issue if there are still runnables that are queued.  This is added at the end of the queue, and then we set the shutting down flag which means we won't add anything else to the queue.
(In reply to comment #5)
> It's not an issue if there are still runnables that are queued.  This is added
> at the end of the queue, and then we set the shutting down flag which means we
> won't add anything else to the queue.

to sum up irc discussion, favicons are more complicated and involve more runnables that are queued up later. thus this won't work for them.
Attached patch v1.1Splinter Review
per comments, + more correct
Attachment #491225 - Attachment is obsolete: true
Attachment #491385 - Flags: review?(mak77)
Attachment #491225 - Flags: review?(mak77)
Comment on attachment 491385 [details] [diff] [review]
v1.1

omponents/places/src/History.cpp
>+++ b/toolkit/components/places/src/History.cpp
>@@ -863,10 +863,6 @@ History::~History()
>                  "Not all Links were removed before we disappear!");
>   }
> #endif
>-
>-  // Places shutdown event may not occur, but we *must* clean up before History
>-  // goes away.
>-  Shutdown();
This is safe because we used to have to tear down a hashtable.  We don't do that anymore, so we don't need to call shutdown in our destructor (which we don't want to do anyway).

>+++ b/toolkit/components/places/src/nsFaviconService.cpp
>@@ -942,7 +942,7 @@ nsFaviconService::FinalizeStatements() {
> 
>   // Finalize the statementCache on the correct thread.
>   nsRefPtr<FinalizeStatementCacheProxy<mozIStorageStatement> > event =
>-    new FinalizeStatementCacheProxy<mozIStorageStatement>(mSyncStatements);
>+    new FinalizeStatementCacheProxy<mozIStorageStatement>(mSyncStatements, this);
This is safe because we'll never call this method in our destructor.
Attachment #491385 - Flags: review?(mak77) → review+
With commit message.  Can land!  Yay!
http://hg.mozilla.org/projects/places/rev/af7e6f7cbf16
Whiteboard: [fixed-in-places]
http://hg.mozilla.org/mozilla-central/rev/af7e6f7cbf16
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: