If manager_p->bytes_needed == 0, jerry_get_context_data() should return
NULL pointer. Additionally init_cb, deinit_cb and finalize_cb should be
called with NULL pointer in this case.
JerryScript-DCO-1.0-Signed-off-by: Csaba Osztrogonác oszi@inf.u-szeged.hu
This patch adds a new finalize_cb callback to jerry_context_data_manager_t.
The callback is run as the very last thing in jerry_cleanup, after the VM has been torn down entirely.
There was already the deinit_cb, which is run while the VM is still in the process of being torn down.
The reason the deinit_cb is not always sufficient is that there may still be objects alive (because they still being referenced) that have native pointers associated with the context manager that is being deinit'ed.
As a result, the free_cb's for those objects can get called *after* the associated context manager's deinit_cb is run. This makes cleanup of manager state that is depended on by the live objects impossible to do in the deinit_cb. That type of cleanup can only be done when all values have been torn down completely.
JerryScript-DCO-1.0-Signed-off-by: Martijn The martijn.the@intel.com
This approach has the benefit that it does not require any *a priori*
initialization, and that each context pointer is identified by the way
in which it was created. Additionally, retrieving the context pointer
now requires that the entity responsible for creating/destroying it
(the manager) be given. Since managers are stored in global static
const structures, they should not normally be visible across source
files, and thus there should be no danger that a context item will be
retrieved by the wrong manager and thus cast into the wrong data type.
Since the items are stored in a linked list, their number will be
limited to exactly as many as are needed for a given context, with the
caveat that storing too many on a context will cause slow retrieval.
Thanks @mhdawson for the idea!
Fixes https://github.com/jerryscript-project/jerryscript/issues/1845
JerryScript-DCO-1.0-Signed-off-by: Gabriel Schulhof gabriel.schulhof@intel.com
