[webkit-dev] Could it be possble to run WebKit from different threads (not simultaneously)?

[Pedriana, Paul]

>I am a little confused by the form of this question.
> What you should be looking for is aspects of WebKit that do not work with 
> that execution model. You don't need to find the things that "could potentially 
> support" it. You need to find the things that don't work. But maybe that's what you mean.

Yes, that's what I meant. Sorry for the wording.

> It's straightforward to get this mostly working, probably a matter of weeks. Given our 
> experience with iOS I would say that getting it to work reliably is probably a multi-month 
> or even multi-year project for a determined team with multiple WebKit experts.

That's for enabling it to run in multiple threads at separate times? I wouldn't think #1 and #3 
would be a problem for us, as we have tight control on our side over when WebKit is entered.
It's not clear to me at this point what we would need to do about AtomicStringTable and its usage.

Thanks.



-----Original Message-----
From: Darin Adler [mailto:darin at apple.com] 
Sent: Monday, May 27, 2013 1:25 PM
To: Pedriana, Paul
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Could it be possble to run WebKit from different threads (not simultaneously)?

On May 27, 2013, at 1:07 PM, "Pedriana, Paul" <ppedriana at ea.com> wrote:

> We understand that for various reasons WebKit cannot run in multiple simultaneous threads. But could be possible to execute it from two different threads, though -never at the same time-? The reason for this is we want to fit it within our application's job-based work scheduling scheme so that WebKit's usage of the CPU can be shared efficiently with other threads in the process (e.g. 3D code, AI code, etc.).

It's quite difficult to do this successfully. The iOS port does this, and it's a source of complexity and implementation difficulty that we'd like to revisit. We think the WebKit2 model works better, with separate processes.

> When we look at the JavaScript stack base/extent tracking for garbage collection, while it can't run in multiple threads simultaneously, it does seem like it could execute in different threads at different times, as long as the stack extents are re-calculated for the thread upon entry into WebKit.

The JavaScript engine fully supports working on multiple threads. We use it that way on at least Mac, iOS, and Windows. For example, the CFNetwork networking library runs JavaScript on network loading thread.

> Are there other thread-specific aspects of WebKit that could potentially support such execution in separate threads at separate times?

I am a little confused by the form of this question.

What you should be looking for is aspects of WebKit that do not work with that execution model. You don't need to find the things that "could potentially support" it. You need to find the things that don't work. But maybe that's what you mean.

Generally speaking the issues are:

1) Non-thread-safe data structures, such as the reference counts in all the RefCounted objects. Those aren't a problem if you are careful and never access them from multiple threads. Doing so is a lot more difficult than it sounds.

2) Globals. One of the most troublesome globals is the AtomicStringTable.

3) Run loop abstraction, and "call on main thread". The MainThread.h header.

It's straightforward to get this mostly working, probably a matter of weeks. Given our experience with iOS I would say that getting it to work reliably is probably a multi-month or even multi-year project for a determined team with multiple WebKit experts.

-- Darin