-
rswindell authored
running a JavaScript module would crash (e.g. segfault) sbbs: Create and use a separate JS runtime, context, and global object/scope for global hotkey events. This means that the hotkey won't benefit from any previously loaded/required scripts, possibly effecting the performance of the first invocation of the hotkey handler. Subsequent JS hotkey events will reuse the same runtime/context/global, so they'll execute fast(er). One questionalbe change to js_execfile(): With the JS_GC (garbage collection) call *before* the JS_ENDREQUEST() call, the process would crash in libmozjs. Moving the JS_GC() call to *after* the JS_ENDREQUEST() resolved this issue and I'm not clear why. This 'js_cx' parameter here is not always sbbs_t::js_cx. When called to handle a JS hotkey event, it's sbbs_t::js_hotkey_cx, so it shouldn't interfere with the sbs_t::js_cx being used by the currently executing JS module (shell or door). <scratches chin>
rswindell authoredrunning a JavaScript module would crash (e.g. segfault) sbbs: Create and use a separate JS runtime, context, and global object/scope for global hotkey events. This means that the hotkey won't benefit from any previously loaded/required scripts, possibly effecting the performance of the first invocation of the hotkey handler. Subsequent JS hotkey events will reuse the same runtime/context/global, so they'll execute fast(er). One questionalbe change to js_execfile(): With the JS_GC (garbage collection) call *before* the JS_ENDREQUEST() call, the process would crash in libmozjs. Moving the JS_GC() call to *after* the JS_ENDREQUEST() resolved this issue and I'm not clear why. This 'js_cx' parameter here is not always sbbs_t::js_cx. When called to handle a JS hotkey event, it's sbbs_t::js_hotkey_cx, so it shouldn't interfere with the sbs_t::js_cx being used by the currently executing JS module (shell or door). <scratches chin>