please expose js_ThreadDestructorCB as a callback to consumers

RESOLVED INACTIVE

Status

()

Core
JavaScript Engine
--
enhancement
RESOLVED INACTIVE
10 years ago
3 days ago

People

(Reporter: timeless, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
XPConnect and JSD need to know when a thread is dead, and they need to know *before* JS finalizes things. imo, The best way for this to happen is for JS to provide register and unregister methods for this.

the definition of before is very simple:
js_ThreadDestructorCB(void *ptr)
  <must be called here>
     * Check that this thread properly called either JS_DestroyContext or
     * JS_ClearContextThread on each JSContext it created or used.
  <before dying here>
    JS_ASSERT(JS_CLIST_IS_EMPTY(&thread->contextList));

notes:
* the reason for unregister is that if a module needs to unload before js does, it can't have js randomly calling this method (or any other).
* relying on chaining is asking for problems (see unload)

i haven't quite figured out in which order xpconnect and jsd would want to be called,

offhand, i think this is correct [for gecko]:
>js_ThreadDestructorCB 
 >jsd_ThreadDescructorCB
 <jsd_ThreadDescructorCB
 >xpc_ThreadDescructorCB
 <xpc_ThreadDescructorCB
<js_ThreadDestructorCB 

and i believe that's possible using:

JS_RegisterThreadDestructor(rt, xpc_ThreadDescructorCB, xpc_opaque)
JS_RegisterThreadDestructor(rt, jsd_ThreadDescructorCB, jsd_opaque)
with conventions of last registered is first called. (LIFO/stack)

not called but available:
JS_UnregisterThreadDestructor(JSRuntime*, JSThreadDescructorCB*, void*)

note that there is a need for multiple rt support, jsdb uses 4 runtimes and each runtime has its own rules and its own local data. I'm not absolutely certain that the opaque pointer is necessary, however having one and not using it is a lot better than not having one and needing it.

wrt order for runtimes, I believe it's sufficient to simply do callbacks based on global registration order (interleaving callbacks if someone from an earlier runtime decides to register after someone from a later runtime).

xpconnect would use this to delete objects from a thread local "dying" list, this would enable me to finish off fixing "xpconnect doesn't free objects from the right thread when dom pins gc to the main thread".

jsd would just use this to let its consumers free their thread local states, in the case of jsdb, that's basically a per thread context used to do work. I think jsd itself will use it for the same purpose (although I'm not certain, I'm still working out that detail).

fwiw, the test world for jsdb is basically:
funcs.js:
function nop(){}
function trw(){throw 1;}
test1.js:
 load("funcs.js");scatter([trw,nop]);quit();
test2.js:
 load("funcs.js");scatter([nop,trw]);quit();
test3.js:
 load("funcs.js");scatter([trw,trw]);quit();
where debugger.js is written so that it simply logs exceptions and lets the victim suffer from them as if it wasn't present.
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Comment 1

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.