[
https://issues.apache.org/jira/browse/COUCHDB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769768#action_12769768
]
Mike Hommey commented on COUCHDB-542:
-------------------------------------
This sounds reasonable, though I'd have a comment to add to what you describe
as the current behaviour for runaway scripts. Disclaimer: I don't know the
couchdb code, nor spidermonkey deep internals. I'm afraid there could be some
subtle memory leaks if you forcibly terminate the javascript engine without
going through the operationcallback, which could be used to gracefully
terminate the engine. The latter would be better, I think, except if what you
mean by forcibly terminating by the Erlang VM is that a separate process,
handling javascript, is killed, in which case, there's no cleanup to do.
> Fix for COUCHDB-288 makes JS_MaybeGC not called
> -----------------------------------------------
>
> Key: COUCHDB-542
> URL: https://issues.apache.org/jira/browse/COUCHDB-542
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
> Reporter: Mike Hommey
>
> The fix for COUCHDB-288 only basically replaces JS_SetBranchCallback with
> JS_SetOperationCallback, which is not enough for the callback to be
> triggered. The problem is that basically, the operation callback API has now
> nothing to do with the previous branch callback API, and is not called at
> each branch call at the JS level. Actually, it is not called at all, except
> if JS_TriggerOperationCallback is used. Typically, this needs to be done
> either from a signal handler or a watchdog thread, in which case the test
> inside the callback is pretty pointless.
> See
> http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/a4d1fe147761aacb/e61d2592faf4ef72?lnk=gst&q=js_setoperationcallback#e61d2592faf4ef72
> for reference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
