On Aug 15, 12:14 pm, Erik Corry <[email protected]> wrote:
> 2009/8/15 Erik Anderson <[email protected]>:
>
>
> > With javascript in normal browsers, I'm fairly certain that there is
> > only one thread active (from the point of view of the script anyhow).
> > While a single function is running no events occur, the screen may not
> > even update, and the page in general goes unresponsive (I'm talking in
> > general, my experience is mostly with IE, Chrome may be different).
> > Google Gears attempts to add the concept of multithreading to
> > JavaScript but the communication pathway is extremely limited, I'm
> > guessing to prevent interaction between scripts running in the two
> > pages.
>
> As you say there are basically no threads in JavaScript. Therefore
> the threading support in V8 is very simple. Normally you only use V8
> in one thread. That's nice and simple. If you want to use more than
> one thread you have to make use of the V8::Locker class from
> include/v8.h. See that file for more details. This puts a single big
> lock around everything V8 does. So although the program as a whole
> can have more than one OS thread that uses V8 there can be only one
> thread at a given time that is using V8. If the thread owns the mutex
> it can use V8, and if it doesn't then it can't. Only one thread can
> own the mutex at a time.
Okay, so from this it sounds like a context is NOT the same thing as a
webpage in V8 and that they interfere with each other. That's rather
disappointing. Can I then create a separate V8 for each "page" in the
program to force them to be independent, or would the instances find
out about each other and force the supervisor program into wrangling
them into separate processes like Chrome does?
> > The second question has to do with suspending threads of execution.
> > In a browser there are a number of long-running commands that contain
> > what I describe as "their own message pump". If you do an alert('hi')
> > or issue a synchronous XHR request then you are liable to find some of
> > your own code executing beneath that call on the call stack (whether
> > triggered by an event, setTimeout, or whatever).
>
> I don't think you'll find that in Chromium. It is theoretically
> possible with V8. The thread waiting for the OK button in the alert()
> command could release the V8 mutex (for example with a V8::Unlocker
> object - see include/v8.h) and other threads could get the mutex and
> run. As I said this isn't done in Chromium. In Chromium nothing
> happens JS-wise while the alert() is active. (I'm ignoring HTML5
> worker threads here - they are fairly independent of the rest of the
> browser.
So Chrome doesn't permit any javascript to execute within an alert()?
I guess I shouldn't be too surprised, but at least it's better than IE
not even refreshing the screen (!) while any javascript is running.
--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---
