This also fixes a leak in the `object_dom` testcase, where the DOM extension
returns an object with refcnt 1 but object_store refcnt 2, causing
READY_TO_DESTROY to return false. Don't try to be fancy, just use the
standard PHP destructor.
zend_update_property does not own the value after the call; we need to
do the deref ourself. Tweaks to the getter based on a better understanding
of the zend_read_property API.
Test against php 5.3, 5.4, and 5.5 -- which incidentally works around
the 'make test always succeeds' bug in php 5.3 and 5.4
(https://bugs.php.net/bug.php?id=60285).
('make test' may always succeed, but we still test against 5.3 and 5.4 to
ensure that we build correctly w/o errors on these php versions.)
The timer_ctx was being popped & freed in terminate_execution, from the
timer thread (not the main thread), and then popped again in the main
thread when execution was aborted. Do all pop/free work in main thread.
Also, remember to pop the timer_ctx when just a memory limit is set.
Deleting the global object implicitly deletes all the properties,
i.e. PHP objects we previously attached to it (and for which we
increased the reference counter).
Since the following idle notifications trigger the weak callbacks,
the references on the PHP objects are finally decreased.
Before the idle notifications to V8 were sent without a special
Isolate entered, which results in V8 using it's default isolate
(which we don't use at all). Hence those were pretty useless
anyways (if they were called, which was unlikely).
Besides V8 seems to not trigger the weak object callbacks if
the isolate is destroyed, hence the PHP objects we add-ref'ed
before will leak.
Therefore this removes the previous idle notification logic
and forces garbage collection from the V8Js object destructor.
If ZTS is disabled, the v8js_globals instance is declared right
in the BSS and hence automatically initialized by C++ compiler.
Most of the variables are just zeroed.
If ZTS is enabled however, v8js_globals just points to a freshly
allocated, unitialized piece of memory, hence we need to
initialize all fields on our own. Likewise on shutdown we have to
run the destructors manually.
Use the NamedPropertyHandler feature of v8 to wrap accesses to PHP properties
and methods from JavaScript. This enables us to support property
set/delete/query.
The `in` and `delete` operators in JavaScript work like the `isset()` and
`unset()` functions in PHP. In particular, a PHP property with a null
value will not be `in` the JavaScript object. (This holds when enumerating
all properties of an object as well.)
Because JavaScript has a single namespace for both properties and methods,
we allow the use of the `__call` method on a PHP object (even if the
PHP class does not natively define the `__call` magic function) in order
to unambiguously invoke a method. Similarly, you can prefix a property
name with `$` to unambiguously access the property. (When enumerating all
properties, properties are `$`-prefixed in order to ensure they are not
conflated with method names.)
This avoids unnecessary calls to Isolate::GetCurrent() in the implementation.
By standardizing on the V8JS_SYM and V8JS_STR macros we also standardize on
UTF-8 encoding for v8 strings.
Before a property was exported to V8 if it was assigned a value
during normal code execution. However if the value was assigned
(hard coded) on class level it wasn't exported.
