Closed
Bug 614790
Opened 14 years ago
Closed 14 years ago
Bookmarks roots init could be locking with the first visit addition
Categories
(Toolkit :: Places, defect)
Toolkit
Places
Tracking
()
RESOLVED
FIXED
mozilla2.0b9
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: mak, Assigned: mak)
References
Details
(Whiteboard: [fixed-in-places])
Attachments
(1 file, 1 obsolete file)
6.38 KB,
patch
|
sdwilsh
:
review+
|
Details | Diff | Splinter Review |
roots are read from the database on startup, around the same time the first visit is added.
Since all database accessed are serialized, this can end up being a problem.
We cannot initialize roots asynchronously though, since not all the APIs are asynchronous. A possible solution is to clone the connection and read them from the cloned connection.
Assignee | ||
Comment 1•14 years ago
|
||
this blocks Places branche merge since it's one of the causes of our Ts regression.
it is already tested by bookmarks tests.
blocking2.0: --- → ?
Flags: in-testsuite?
Assignee | ||
Comment 2•14 years ago
|
||
Attachment #493240 -
Flags: review?(dietrich)
Assignee | ||
Comment 3•14 years ago
|
||
I'm waiting try results regarding Ts on all platforms for this bug and bug 614787
Assignee | ||
Comment 4•14 years ago
|
||
Comment on attachment 493240 [details] [diff] [review]
patch v1.0
I prefer waiting for this review, while it's correct it's possible I have to do further enhancements for locking.
Attachment #493240 -
Flags: review?(dietrich)
Assignee | ||
Comment 5•14 years ago
|
||
This also delays the creation of the bookmarks service, since we don't need it on init.
I also have a patch to make history serve cloned connections, doesn't look like it's needed, but has some interesting side effect, like having a single point to handle creation, setup and closing of the clones (http://hg.mozilla.org/try/rev/63ff36bc8fba), do you think it's worth filing a bug or we don't want to follow such a way?
Attachment #493240 -
Attachment is obsolete: true
Attachment #493511 -
Flags: review?(sdwilsh)
Comment 6•14 years ago
|
||
(In reply to comment #5)
> I also have a patch to make history serve cloned connections, doesn't look like
> it's needed, but has some interesting side effect, like having a single point
> to handle creation, setup and closing of the clones
> (http://hg.mozilla.org/try/rev/63ff36bc8fba), do you think it's worth filing a
> bug or we don't want to follow such a way?
We should file a bug for it, but I think we should punt on fixing it until after Firefox 4.0.
Updated•14 years ago
|
blocking2.0: ? → betaN+
Comment 7•14 years ago
|
||
Comment on attachment 493511 [details] [diff] [review]
patch v1.1
r=sdwilsh
Attachment #493511 -
Flags: review?(sdwilsh) → review+
Assignee | ||
Comment 8•14 years ago
|
||
Flags: in-testsuite? → in-testsuite+
Whiteboard: [fixed-in-places]
Comment 9•14 years ago
|
||
(In reply to comment #8)
> http://hg.mozilla.org/projects/places/rev/c5c6f317e9b7
http://hg.mozilla.org/mozilla-central/rev/c5c6f317e9b7
Blocks: FF2SM
Assignee | ||
Updated•14 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
Updated•14 years ago
|
Version: unspecified → Trunk
You need to log in
before you can comment on or make changes to this bug.
Description
•