D8 contains a lot of things from v8::internal:: and apparently has never
been
able to be linked to a shared V8 library. I removed the #if
(defined(USING_V8_SHARED)||defined(V8_SHARED) lines since I copied those
directly from the sample shell where it makes sense. Though note that as
consequence, the sample shell cannot handle --isolate when compiled with the
shared library.
Aside from the things I added in this CL there are a lot of other things
that
would cause trouble if linked with shared library. So my plan is to land
this CL
first and then, as next step, adopt your idea of creating a wrapper to
expose
needed parts from the shared library so we can eventually link d8 with the
shared library.
I chose to use a mutex because using lockers in different isolates would
still
result in concurrent call to Shell::CreateEvaluationContext. Even though
those
concurrent calls are in different isolates, it still causes a failure when
traversing extensions when creating a context.
http://codereview.chromium.org/7318002/diff/1001/src/d8.cc
File src/d8.cc (right):
http://codereview.chromium.org/7318002/diff/1001/src/d8.cc#newcode676
src/d8.cc:676: context_mutex_->Lock();
On 2011/07/08 08:09:12, Søren Gjesse wrote:
On 2011/07/07 16:04:49, yangguo wrote:
> mark critical section because creating a context is not thread-safe
Isn't this already handled by the use of lockers?
Unfortunately, no. As it turns out, lockers only lock inside the same
isolate. So when I have multiple threads with their own isolates
respectively, there may be concurrent accesses call to this method,
causing failures. I think a mutex is the best solution to deal with
this.
http://codereview.chromium.org/7318002/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
