Added the last test (3 isolates on 3 threads in parallel).
Adding Vitaly (welcome back from vacation!) to take a look at how the API he
designed now can pass tests! :-P
Some ideas:
1. Default isolate is created always (not initialized though) during static
initialization.
2. The thread that does initialization or is created with an isolate as a
constructor parameter are getting the isolate into TLS, but not
PerIsolateThreadData since they did not yet enter the thread. The thread
having
isolate in TLS but not PerIsolateThreadData 'has affinity' to the isolate.
This
is transparent to API users and is only needed to support old behavior of
API
(some threads 'automatically' get affinity to default isolate, for example
the
thread that performs static initialization, since it has to have
Isolate::Current() return somethign reasonable)
3. PerIsolateThreadData in TLS pointing to the isolate is used as indicator
that
thread not only has 'affinity' to an isolate but also Entered it.
4. Each Isolate has a stack of threads that entered it. If the same thread
enters many times, a counter in stack item is incremented instead of
pushing the
stack again.
5. Isolate can only be Disposed when its thread stack is empty (all threads
Exited it)
6. Default isolate, when Disposed, is not actually deallocated - merely
Deinit'ed. This returns most of the resources. Deallocating the default
isolate
is problematic because old API behavior require it always be around.
7. There are new exciting tests! Include one thread using multiple isolates
and
multiple threads using their individual isolates. These cases do not require
Lockers. I'm planning to add Lockers support soon, so it'll be possible to
run
multiple threads on the same non-default isolate.
http://codereview.chromium.org/2836067/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
