We don't know whether the V8Js object dtor or the script (resource)
dtor is called first. Nevertheless they depend on each other as
we must not simply Reset the persistent v8::Script if the v8::Isolate
was disposed before.
Now the V8Js dtor iterates over all script resources and resets the
persistent v8::Script instances; leaving an invalidated resource
object (which cannot be called anymore).
Currently it just enables RSHUTDOWN code that should print
memory usage statistics. However the code implements API calls
that aren't supported anymore (for a long time).
The V8::TerminateExecution does *not* immediately terminate execution
as its name might suggest. It just marks the given isolate as
"to terminate" and the execution thread checks - from time to time -
whether to terminate. For v8 itself this is not problematic as
the call is thought to stop long-running scripts executed in the
browser context.
As v8js exposes this function to JavaScript with the exit() method,
this behaviour is confusing. In order to stop code execution right
at the exit() call, v8js enters an endless loop and waits for v8
to terminate execution within it.
Added a "%s" so both messages are matched:
* Extension or internal compilation error: MakeReferenceError in handlebars at line 1.
* Extension or internal compilation error in handlebars at line 1.
We need to reset V8JSG(timer_stop) and V8JSG(timer_thread), otherwise
subsequent requests fail on multi-request SAPIs.
If we don't reset those, a subsequent request will not start a new timer
thread (as V8JSG(timer_thread) != NULL), but will try to join the thread
(once more) in GSHUTDOWN as V8JSG(timer_thread) still is non-NULL and
hence cause program termination.
Just tested it, v8js builds correctly with 3.24.6 and fails to build
against 3.24.5 due to `RequestInterrupt' being undefined.
Syncing the check in config.m4 (used to test 3.21.12 or newer) against
README.md file (which stated 3.24.10 or newer).
