couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] Commented: (COUCHDB-542) Fix for COUCHDB-288 makes JS_MaybeGC not called
Date Sat, 24 Oct 2009 22:27:59 GMT


Paul Joseph Davis commented on COUCHDB-542:


Good catch on that. When I wrote the patches that ended up with what we have now I was more
worried about getting the thing to compile properly for all the different versions of Spidermonkey
than anything else. I didn't even dig deep enough to see that I was supposed to be setting
up a signal handler to call that periodically.

The more than I read about this the more I think the proper fix is to just ixnay the whole
callback situation and forget that it ever existed. For reference, my knowledge of that callback
is that it's used to prevent infinite loop scripts as well as trigger garbage collection periodically.

CouchDB solves the runaway script issue by requiring that all communication to external servers
complete in a defined set of time (default of 5 seconds). When a script exceeds this threshold
its forcibly terminated by the Erlang VM and eventually replaced when needed.

As to garbage collection, the current protocol runs the "reset" command each time an OS process
is retrieved from the pool. At this point JS_GC() is called forcing collection. JS_MaybeGC
is also called for every line of input which will save us with long checkouts during things
like view building and _changes filtering.

So, yeah, I think I just convinced myself that we should probably just delete the whole thing.
Unless of course I'm missing a case where having JS_MaybeGC calls are required and not being
called. What do you think?

> Fix for COUCHDB-288 makes JS_MaybeGC not called
> -----------------------------------------------
>                 Key: COUCHDB-542
>                 URL:
>             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
for reference.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message