I have a C++ application with several custom/native JavaScript objects that has been working fine on js 1.7.0 for years but in light of all the new features that have been added it was time to update to SpiderMonkey 24. I have built the new library and made the necessary changes to our application (for it to compile, link, and run) but I'm running into consistent faults when calling JS_DestroyContext (it crashes doing the GC). If I use JS_DestroyContextNoGC I don't get the crashes, although I assume that means my application will either leak memory or crash at some other time (is that assumption accurate?). The Migrating_to_SpiderMonkey_24 guide is littered with ...insert details here... so that wasn't particularly helpful. My assumption is that the fault is related to my lack of understanding about what the new version of SpiderMonkey requires regarding threading.
Basically my application creates a bunch of JSRuntime's (one per logical service), and inside each it creates a bunch of related JS_NewContext's (one per connection to each logical service) and defines some custom objects in each. The application is multiple threaded, and scripts on a context can run on any of the threads from a thread pool. I provide custom locking such that no two contexts are executing in the same runtime at any one time. When a script requires running, I do the custom locking, and additionally wrap the execution with JSAutoRequest and JSAutoCompartment.
1) Is my approach sufficient? 1b) Do I have to lock such that no two runtimes are active at one time too?
2) I did not compile SpiderMonkey with --enable-threadsafe (and when I did, I couldn't get it to compile with NSPR on x64, which did compile OK)... is this required given my use?
3) (secondarily) performance is not critical, so I did compile it with --disable-ion --disable-yarr-jit; is that sufficient to turn off all JIT? I've noticed the library is still quite a bit larger.
Many thanks for any pointers... I'd hate to have to revert to 1.7.0...
