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. 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. 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
