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