On Friday, May 11, 2018 at 2:45:06 PM UTC-4, Ben Noordhuis wrote:
>
> On Fri, May 11, 2018 at 7:36 PM, <jer...@fly.io <javascript:>> wrote:
> > I've been wondering if it's possible to concurrently use v8::Locker.
> >
> > I'm binding to v8 from a single-threaded language that uses fibers for
> > concurrency (Crystal.) Since it's a single thread, v8::Locker is always
> > instantly available.
> >
> > This seems fine, the bigger issue if with Context::Scope.
> >
> > I'm concurrently entering and exiting the same context from multiple
> fibers
> > and I keep stumbling upon:
> >
> > #
> > # Fatal error in v8::Context::Exit()
> > # Cannot exit non-entered context
> > #
> >
> > Which came to make sense to me. I'm passing around a pointer to a
> > Persistent<Context>. In the function I concurrently access, I'm getting
> the
> > Local from it (with the isolate) and creating a Context::Scope. The same
> > Local<Context> might be exited more than once. I expect Enter is a noop
> if
> > the Context has already been entered.
>
> It isn't. Enter() and Exit() calls need to match up.
>
Yea, that makes sense. They do match up, but the function I use to get the
context handle may be called more than once at the same time. I mean, the
same context may be entered multiple times concurrently and exited at
different times. As soon as it's exited once by one of the concurrent
tasks, it will throw that error I pasted if it's exited again.
void __crystal_ctx_scoped(char *id);
void v8_with_ctx_scope(Isolate* iso, Context* ctxptr, char* id) {
v8::HandleScope handle_scope(iso);
v8::Local<v8::Context> ctx = ctxptr->Get(iso);
{
v8::Context::Scope context_scope(ctx);
__crystal_ctx_scoped(id);
}
}
The __crystal_ctx_scoped is a callback exposed from Crystal to C. It
dispatches to the right context via the provided id.
I added the extra curly braces as a test, but I don't think they're
necessary.
> > My fix was to use a fiber-safe mutex to only allow one isolate locking
> and
> > context scoping at any given time.
> >
> > Is this normal? Any way around it?
>
> You may want to take a look at node-fibers. It uses a thread-local
> storage hack to trick V8 into supporting fibers.
>
>
> https://github.com/laverdet/node-fibers/blob/4786aef736ab8285d29e9476e3615abbd3935d37/src/coroutine.cc#L76-L123
>
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Flaverdet%2Fnode-fibers%2Fblob%2F4786aef736ab8285d29e9476e3615abbd3935d37%2Fsrc%2Fcoroutine.cc%23L76-L123&sa=D&sntz=1&usg=AFQjCNEPItMID53iFb6V4Pvr6vxZ3IZrzg>
>
>
I've looked at it a bit. I've also been chatting with its author.
I don't necessarily want fibers to work from within v8 (like node-fibers),
I mostly want to be able to call v8 from any fiber concurrently. But maybe
the requirements for that are similar.
I'm already assigning the stack limit to the stack_bottom (or top depending
on who you're talking to) + padding to the isolate on after each lock.
Apparently that's not enough and it somehow started crashing a bit.
Discussing with the node-fibers authors on maybe fixing that.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
