Re: Threading and runtime / context sharing

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