[webkit-dev] Database in Worker context
dimich at chromium.org
Thu Dec 10 13:09:00 PST 2009
On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane <ericu at chromium.org> wrote:
> On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov <dimich at chromium.org> wrote:
> > Thanks for the link to the prototype code!
> > If I understand it right and the DatabaseManager can not have any other
> > relationship with ScriptExecutionContext but 1-1 and their lifetime is
> > same then it's not clear to me what benefit could be had by effectively
> > splitting a class in two. The fact that DatabaseManager is RefCounted
> > hints that some other object could take ownership of it as well outside
> > lifetime of ScriptExecutionContext, but is this true?
> That's there because the DatabaseThread [and therefore the Database]
> can stick around for a bit after the ScriptExecutionContext is deleted
> if I make it non-refcounted. If I move the DatabaseManager parts into
> the ScriptExecutionContext, then I have to make sure that the SEC
> sticks around until after the Database and DatabaseThread have gone
It feels that there is a new class that does not have a specific lifetime or
relationship to other existing classes, as it is a mechanical part of some
other class rather...
I look at how m_document is used by current Database and it feels that if
SEC had a databaseThread() accessor, then all other methods like
addOpenDatabase etc could be part of DatabaseThread instead, with Database
keeping a pointer to its DatabaseThread. What do you think about this?
> ScriptExecutionContext collects functionality common for Workers and
> > Documents, and as such is a home for a few 'groups' of methods, like a
> > methods to deal with MessagePorts. MessagePort, in turn, has a raw
> > back to ScriptExecutionContext - so it's clear that MessagePorts do not
> > outlive the SEC. Same pattern could be used for
> > ScriptExecutionContext/Database, for consistency. It also simplifies
> > a bit - no need for a special refcounted manager class, and things
> > already implemented.
> Thread in the Document context, but [in Chromium's implementation] NOT
> in the Worker context. I needed a virtual method to distinguish
> between the two cases, since the Database code previously treated
> that virtual method can be moved to Document and SEC instead of DDM
> and WDM.
SEC::postTask is defined - it posts a task from any thread to the one which
thread, for Workers - the thread associated with WorkerThread. I think they
are the same thing - you can just use postTask in place of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev