Re: How to create multiple contexts in different threads?

On Thu, Mar 31, 2016 at 6:13 AM, <[email protected]> wrote:

> On Wednesday, March 30, 2016 at 9:17:53 PM UTC+2, [email protected]
> wrote:
> > On Wednesday, March 30, 2016 at 9:09:46 PM UTC+2, [email protected]
> wrote:
> > > PR_GetCurrentThread () also returns 0.
> >
> > That should not happen according to the documentation. I added an
> assertion in isLock to make sure it was not because gdb and it fails:
> > Assertion failure: PR_GetCurrentThread()!=nullptr, at
> /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:537
> >
> > Any idea about why this happens? Should I ask on a NSPR mailing list
> instead?
>
> I think I solved most of my problems.
>

I'm relieved to hear it.

The PR_GetCurrentThread problem was solved by using --with-system-nspr
> configure option. I am still unsure where the broken NSPR that was used
> before came from.
>

Can GDB tell you this? Perhaps with:
  (gdb) info sharedlibrary
or by stepping into the PR_GetCurrentThread function.

I'd really like to understand what's going on here. I believe the default
is --enable-posix-nspr-emulation, which means that no NSPR is linked or
#included at all. Instead the shim code in js/src/vm/PosixNSPR.cpp is used.
But I don't see how that file's implementation of PR_GetCurrentThread could
possibly return nullptr, no matter how broken pthreads is.

I then got some race with signal handler installation. From
> AsmJSSignalHandlers.js:1011 (js::EnsureSignalHandlersInstalled)
>     // All the rest of the handlers are process-wide and thus must only be
>     // installed once. We assume that there are no races creating the first
>     // JSRuntime of the process.
> So I created a parent runtime before every other to make sure there was no
> race when initializing global data.
>

This is documented in the comment on JS_NewRuntime in jsapi.h, at least.
The state of the documentation, admittedly, is awful.

And there was some segfault because of undefined DEBUG (js-config.h only
> defines JS_DEBUG, but DEBUG is used in some public headers, is that a bug?).
>

Well, yes. ...But looking closer, I'm now unsure just how we should fix it.
Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=1261161>.

Thanks for your help.
>

I'm not sure we were any help to you at all, but thanks for posting here
and thanks for following up.

-j