[Webkit-unassigned] [Bug 50825] GeolocationPositionCache should do database access on background thread

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50825





--- Comment #4 from Jeremy Orlow <jorlow at chromium.org>  2010-12-20 06:33:13 PST ---
(In reply to comment #3)
> > no newline
> Will do
> 
> > This one line is doing a lot.  Maybe the ++numUsers should stay outside of the if statement?
> Will do
> 
> > Is there any other thread we can share?  Or will this be used for anything else?
> I don't have any plans to use this thread for anything else. Is there a precedent for using a thread for multiple tasks? Do you have a suggestion as to which thread I could use.

There's not much precedent for threads in general.  In the few places that use them, it's one function per thread.  So I guess leave it, but maybe put a FIXME combine with other threads?  or something.

> > I don't think we typically use /* style comments.
> Will do
> 
> > Everything in this can block the main thread.
> > Only lock to get a snapshot.  Don't hold it.  Otherwise, there's no point...
> The reason I lock early is that I also need to protect access to m_databaseFile (I admit my mutex is badly named). There's still benefit, as the WebCore thread can now treat this as a 'fire and forget' operation. It's unlikely that the DB thread will be in the middle of a read/write when the WebCore thread next asks for the cached position.
> 
> One solution would be to use multiple mutexes and use finer grained locking, but that adds more complexity. WDYT?

Just use one mutex and {}'s to control the scoping of it.  You can lock it to get the data, do the read, and then lock again to set the values (and verify the constraints are still as expected...if not, I guess loop and run again?).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.