[Webkit-unassigned] [Bug 22725] Make SQL database storage work in Workers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 8 22:59:59 PST 2010


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





--- Comment #11 from Dmitry Titov <dimich at chromium.org>  2010-01-08 22:59:57 PST ---
(In reply to comment #9)

> > > +bool Document::isJavaScriptThread() const
> > > +{
> > > +    return WTF::isMainThread();
> > > +}
> > 
> > I think this new virtual function is redundant. For the cases it is used in, it
> > always means "not the database thread", and it seems the database thread ID is
> > available in all points of use.
> 
> The database thread is available for checking anywhere you can call
> isJavaScriptThread.  However, that's not a sufficient check; since the JS
> thread isn't the main thread in worker context, it's also important to verify
> that we're not on the main thread there.

Perhaps, there is a naming issue here that makes me think this doesn't belong -
why "JavaScript" thread? Perhaps it should be "isContextThread()"? It would
check that current thread is the one that 'postTask()' targets... There are
patches attempting to allow other languages to be run as 'script'. 

On top of that, I hope Database would never be used on 3 threads. Currently,
all DOM objects created and used under SEC are accessed on 'context thread'
only. In case of Workers this is a Worker thread. This is by design since none
of DOM objects are natively cross-thread-capable. For example, XMLHttpRequest
does not need to assert or do different things depending on which thread it is
running - and in the only place it needs, it uses explicit ThreadableLoader
class that explicitly encapsulates the cross-thread logic. Timers simply use
TLS and are oblivious to the thread they are used on. It would be really messy
if we had to assume that DOM objects can be accessed from different threads.

It seems that existing Database code uses isMainThread() as synonym of
!isDatabaseThread() and if it is so then the new method can be avoided. At
least this seems to be true in this patch. Please correct me if I miss
something.

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



More information about the webkit-unassigned mailing list