Re: Threading and runtime / context sharing

The landscape of this code has changed significantly since the above posts
on this thread. Bill (CCed) is the right person to ask about it now.

On Fri, Jul 28, 2017 at 8:38 AM, <[email protected]> wrote:

> Hi Bobby, I came to this thread because I'm having the same issue like
> Robin. I have been working with spidermokey as a embeddable engine since
> versión 1.5 (currently porting some develop from 1.8.5 to 24).  For years I
> avoided to use v8 as an alternative engine because the limitation in
> multithreading environment and I will be glad to work in this issue to keep
> me, and all others developers, away from other engines.
> So, some mentoring will be welcome.
>
> On Tuesday, July 28, 2015 at 4:11:12 PM UTC-3, Bobby Holley wrote:
> > On Mon, Jul 27, 2015 at 10:48 PM, Terrence Cole <[email protected]>
> wrote:
> >
> > > I think it is still presumed to be slow, so is rarely used; at least
> this
> > > is the case in the GC. The GC's main use at the moment is for making
> > > assertions about global state in deep call stacks where it's
> cumbersome to
> > > thread a context, particularly if it has to be debug-only.
> > >
> >
> > Great.
> >
> >
> > >
> > >
> > >> If so, I think we should do that (to avoid more dependencies), which
> has
> > >> the added benefit of solving Robin's problem.
> > >>
> > >
> > > I think this is a reasonable plan, although, as with anything threading
> > > related, caution is warranted lest we end up back in the dire straights
> > > that caused us to go strictly single-threaded in the first place.
> > >
> >
> > I'm not suggesting a change to the threading model. I'm just suggesting
> > that we do all of our threading operations (TLS lookups, "are we on this
> > thread", etc) indirectly via a virtual methods on an interface that the
> > embedder implements.
> >
> > Doing this sooner rather than later will probably make our lives easier
> in
> > the long run. Robin, would you be willing to do this if someone mentors
> you?
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine