Bug 1559659 Comment 28 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
(In reply to Jan de Mooij [:jandem] from comment #26)
> It seems to me the underlying problem is that we don't lock when we call clearThread() (and the context's threadId is not an Atomic either). We could rename setThread/clearThread to setHelperThread/clearHelperThread and make them take an `AutoLockHelperThreadState&` argument to enforce this. (`AutoLockHelperThreadState` can be forward-declared in JSContext.h if necessary.) What do you think?
The only thing that I can see being a bit weird is when we set the main thread context. Maybe the main thread should have its own set method, or even handle that during JSContext::init() after checking that the new ContextKind is main-thread?
Revision 1 by
on 
(In reply to Jan de Mooij [:jandem] from comment #26)
> It seems to me the underlying problem is that we don't lock when we call clearThread() (and the context's threadId is not an Atomic either). We could rename setThread/clearThread to setHelperThread/clearHelperThread and make them take an `AutoLockHelperThreadState&` argument to enforce this. (`AutoLockHelperThreadState` can be forward-declared in JSContext.h if necessary.) What do you think?

The only thing that I can see being a bit weird is when we set the main thread context. Maybe the main thread should have its own set method, or even handle that during JSContext::init() after checking that the new ContextKind is main-thread?

Back to Bug 1559659 Comment 28