Re: [JS-internals] JS_THREADSAFE, parallelism, and the future (and Windows builds)

2012-10-29 Thread Terrence Cole
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

Re: [JS-internals] JS_THREADSAFE, parallelism, and the future (and Windows builds)

2012-10-29 Thread Brendan Eich
+1 on no mo' JS_THREADSAFE. Also +1 on cutting the NSPR apron-strings. See https://bugzilla.mozilla.org/show_bug.cgi?id=507718 -- almost-three-year-old patch from cjones, r=luke! /be Dave Mandelin wrote: I was reviewing one of the River Trail patches today and I noticed that it had to add

[JS-internals] JS_THREADSAFE, parallelism, and the future (and Windows builds)

2012-10-29 Thread Dave Mandelin
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 ove