On 10/29/2012 05:32 PM, Dave Mandelin wrote:
> I was reviewing one of the River Trail patches today and I noticed that it 
> had to add JS_THREADSAFE everywhere. This seems wrong to me. IIRC, 
> JS_THREADSAFE originally was a build configuration parameter used to decide 
> between:
> 
>  - I want a multithreaded engine, at the cost of some locking 
>    overhead for certain common operations, and
>  - I want a single-threaded only engine
> 
> AFAIK, that distinction is just about gone, so JS_THREADSAFE is now mostly 
> legacy cruft (the name certainly is), but has been pressed into service to 
> decide between:
> 
>  - I want an engine that uses threads to make stuff faster, like
>    GC, compilation, and source compression, and
>  - I want an engine that doesn't use extra threads for that
> 
> Is this still a choice worth making? Most of our users have 2+ cores now, the 
> future is believed to be even more parallel, and everyone wants performance 
> and responsiveness.
> 
> How about we just say it's a library that uses threads, and give (preferably 
> runtime) options to control that usage in ways that people need? I think 
> requiring NSPR to build on Windows is the initial primary pain point. What's 
> the easiest way to hack the build system around this? NSPR is in a full 
> checkout, so it doesn't seem crazy to build NSPR and then SpiderMonkey.

I think we want this gone.  There are some bugs for this already:
720018, 763800, 772722, and 773491.

> It also occurs to me that SpiderMonkey's usage of threads is probably not 
> terribly complex, and people would probably prefer a C++ API. So maybe a 
> small threading library inside SpiderMonkey or mfbt is the thing to do. V8 
> has this, maybe we can use their code.

It would already be gone if not for WindowsXP: it lacks a Condition
Variable.  We could import the pthreads-win32 library, or just keep
using NSPR.

> Dave
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to