Yeah, I know (and hopefully anyone using node-weak knows) that the node-weak callback is a dangerous place to do anything complicated, as you say, like interrupt handlers or signal handlers.
The problem I have isn't what my node-weak callback itself is doing, because I know how to play by those rules -- the problem is that because node-weak used MakeCallback() to invoke *that* callback, it also has the side effect of invoking *all previously requested nextTick callbacks*, which could be anything -- and certainly includes a bunch of code that doesn't know, can't know, to play by those stricter rules. Basically, the MakeCallback behavior I'm observing, when called from a nested context (like what node-weak does when invoking callbacks from GC context), could turn any nextTick callback into an interrupt handler, and I can't possibly write all my nextTick callbacks to be safe enough to run at such times. I agree node-weak is an odd beast, and it's certainly possible that all my troubles originate from my use of it. I'm still curious whether what it's doing is the right way for it and other extensions to go back into V8 and invoke JS code from native code, or is there some other way. If nothing else uses MakeCallback this way, and there's another way for node-weak to invoke just its own callbacks (the ones written to the safety standard of interrupt handlers), I'd call this a node-weak bug and ask it to change to invoke just its own callbacks. If nothing else uses MakeCallback this way but there's no other way for node-weak to invoke just its own callbacks, then the problem would be limited to node-weak users but I'd consider node-weak too dangerous to use. If other things use MakeCallback this way, then the problem isn't limited to node-weak anyway (though as I mentioned in my previous post, I think the problem is much more dangerous the way node-weak exposes it, because if your API function or extension calls MakeCallback and all nextTick callbacks, at least you can tell me to watch out for that API function and I can try to call it only at safe times, but I can't control when GC happens so I can't restrict MakeCallback to safe times). I tried looking around the ~45 uses of MakeCallback in the node codebase per se, outside of node.cc; the majority seem like they're using it perfectly safely (from an OnFoo callback which was registered with libuv directly). Some of the ones in node_crypto.cc look like they might be capable of running in what I'm calling a nested context (with user JS code already on the call stack), but I haven't had time to prove or disprove this hypothesis yet. I also wanted to audit all the other native-code Node extensions I'm using to see whether/how they invoke MakeCallback, but at this point this is largely obscured by nan (even node-weak doesn't call MakeCallback directly), and these codebases are all new to me so this isn't something I can do quickly and I haven't been able to glean anything useful there either yet. I'm pretty sure I could repro the same behavior without node-weak but with the extension in https://github.com/joyent/node/issues/8231, which does directly expose MakeCallback in what I'm calling a nested context. That extension was just to demo/repro some other bug and not real production code; again I don't know whether you're supposed to write code like this, but I take this as some indication that this way of using MakeCallback is not purely limited to node-weak. Thanks again to anyone looking into this -- I am very eager to get to the bottom of it. Matt -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/eca1539a-94b7-4d16-96d5-71a7936bf5ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
