This works fine with V8 < 5.2.50 somehow, but is now (properly) detected
and causing V8 to bail out. Fixed by always setting templates on
other templates and finally use Global-Proxy on context to get the
actually created object instances.
If the v8::Unlocker block is within the zend_try block, then
v8::~Unlocker (dtor) is not called and hence V8 doesn't
re-aquire the lock.
Besides before we re-entered the isolate within zend_try
and hence *before* taking the lock.
Newer V8 versions' toString() converts RegExp objects
just to [object RegExp] (instead of the actual regexp
as before). Work-around by calling GetSource() on the
regexp and create former outhway that way.
This might be perfectly valid, if you're using a third-party module,
which requires a module yet doesn't use it in the code paths hit
and hence you just want to stub it out.
Recent V8 versions (e.g. 4.8.253 or 4.9.19) consider
`IsFunction() = true` for Closure objects from PHP; but earlier
versions didn't.
This ensures consistent var_dump behaviour (sticking to the
behaviour with older V8 versions).
Without the compare function std::map simply compares one
pointer to another. However we need to compare the actual
strings.
Besides we must not efree normalised_module_id on return
of require method, since the pointer was added to
modules_loaded (and is valid until destruction of V8Js
class); instead it is now freed during V8Js object destruction.
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.
