2019-05-22 13:21:02 -07:00
|
|
|
#include "libefl_mono_native_test.h"
|
|
|
|
|
|
|
|
typedef struct Dummy_Part_Holder_Data
|
|
|
|
{
|
|
|
|
Eo *one;
|
|
|
|
Eo *two;
|
|
|
|
} Dummy_Part_Holder_Data;
|
|
|
|
|
csharp: Refactor wrapper lifetime.
Summary:
This commit makes use of the `ownership,shared` and `ownership,unique`
events from Efl.Object in order to avoid the C# wrapper from being
collected while C code holds a reference to the object.
For example, creating a list of items in a for loop and attaching events to
them would fails without this commit, as the C# GC may collect the wrapper.
The basic idea is that we use a `WrapperSupervisor`, which is stored in
the Eo data storage, with a GCHandle allocated for the lifetime of the
underlying Eo object. This supervisor takes care of holding either a
weak C# reference (when in unique mode, allowing the wrapper to be GC'd)
or a hard C# reference (when in shared mode, making the wrapper
non-collectable while the Eo has extra references).
One limitation is that object graphs can leak if a shared object in the
graph - an Eo child for example - stores a hard reference to another
object in the graph as a C# field. In this example, this causes the
parent to always have a hard C# reference (from the child) as the child
is non-collectable due to the parent holding an Eo reference to it.
Depends on D8678
Test Plan: `ninja test` and `make test`
Reviewers: lauromoura, felipealmeida, woohyun, segfaultxavi
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9014
2019-05-31 13:43:11 -07:00
|
|
|
void part_deleted_cb(void *data, const Efl_Event *evt)
|
|
|
|
{
|
|
|
|
Dummy_Part_Holder_Data *pd = data;
|
|
|
|
|
|
|
|
if (evt->object == pd->one)
|
|
|
|
pd->one = NULL;
|
|
|
|
else if (evt->object == pd->two)
|
|
|
|
pd->two = NULL;
|
|
|
|
}
|
|
|
|
|
2019-05-22 13:21:02 -07:00
|
|
|
// Part holder
|
|
|
|
static Efl_Object*
|
|
|
|
_dummy_part_holder_efl_object_constructor(Eo *obj, Dummy_Part_Holder_Data *pd)
|
|
|
|
{
|
|
|
|
efl_constructor(efl_super(obj, DUMMY_PART_HOLDER_CLASS));
|
|
|
|
|
|
|
|
// To avoid an infinite loop calling the same constructor
|
|
|
|
if (!efl_parent_get(obj))
|
|
|
|
{
|
|
|
|
pd->one = efl_add(DUMMY_TEST_OBJECT_CLASS, obj, efl_name_set(efl_added, "part_one"));
|
csharp: Refactor wrapper lifetime.
Summary:
This commit makes use of the `ownership,shared` and `ownership,unique`
events from Efl.Object in order to avoid the C# wrapper from being
collected while C code holds a reference to the object.
For example, creating a list of items in a for loop and attaching events to
them would fails without this commit, as the C# GC may collect the wrapper.
The basic idea is that we use a `WrapperSupervisor`, which is stored in
the Eo data storage, with a GCHandle allocated for the lifetime of the
underlying Eo object. This supervisor takes care of holding either a
weak C# reference (when in unique mode, allowing the wrapper to be GC'd)
or a hard C# reference (when in shared mode, making the wrapper
non-collectable while the Eo has extra references).
One limitation is that object graphs can leak if a shared object in the
graph - an Eo child for example - stores a hard reference to another
object in the graph as a C# field. In this example, this causes the
parent to always have a hard C# reference (from the child) as the child
is non-collectable due to the parent holding an Eo reference to it.
Depends on D8678
Test Plan: `ninja test` and `make test`
Reviewers: lauromoura, felipealmeida, woohyun, segfaultxavi
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9014
2019-05-31 13:43:11 -07:00
|
|
|
efl_event_callback_add(pd->one, EFL_EVENT_DEL, part_deleted_cb, pd);
|
2019-05-22 13:21:02 -07:00
|
|
|
pd->two = efl_add(DUMMY_TEST_OBJECT_CLASS, obj, efl_name_set(efl_added, "part_two"));
|
csharp: Refactor wrapper lifetime.
Summary:
This commit makes use of the `ownership,shared` and `ownership,unique`
events from Efl.Object in order to avoid the C# wrapper from being
collected while C code holds a reference to the object.
For example, creating a list of items in a for loop and attaching events to
them would fails without this commit, as the C# GC may collect the wrapper.
The basic idea is that we use a `WrapperSupervisor`, which is stored in
the Eo data storage, with a GCHandle allocated for the lifetime of the
underlying Eo object. This supervisor takes care of holding either a
weak C# reference (when in unique mode, allowing the wrapper to be GC'd)
or a hard C# reference (when in shared mode, making the wrapper
non-collectable while the Eo has extra references).
One limitation is that object graphs can leak if a shared object in the
graph - an Eo child for example - stores a hard reference to another
object in the graph as a C# field. In this example, this causes the
parent to always have a hard C# reference (from the child) as the child
is non-collectable due to the parent holding an Eo reference to it.
Depends on D8678
Test Plan: `ninja test` and `make test`
Reviewers: lauromoura, felipealmeida, woohyun, segfaultxavi
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9014
2019-05-31 13:43:11 -07:00
|
|
|
efl_event_callback_add(pd->two, EFL_EVENT_DEL, part_deleted_cb, pd);
|
|
|
|
|
|
|
|
|
2019-05-22 13:21:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
return obj;
|
|
|
|
}
|
|
|
|
|
csharp: Refactor wrapper lifetime.
Summary:
This commit makes use of the `ownership,shared` and `ownership,unique`
events from Efl.Object in order to avoid the C# wrapper from being
collected while C code holds a reference to the object.
For example, creating a list of items in a for loop and attaching events to
them would fails without this commit, as the C# GC may collect the wrapper.
The basic idea is that we use a `WrapperSupervisor`, which is stored in
the Eo data storage, with a GCHandle allocated for the lifetime of the
underlying Eo object. This supervisor takes care of holding either a
weak C# reference (when in unique mode, allowing the wrapper to be GC'd)
or a hard C# reference (when in shared mode, making the wrapper
non-collectable while the Eo has extra references).
One limitation is that object graphs can leak if a shared object in the
graph - an Eo child for example - stores a hard reference to another
object in the graph as a C# field. In this example, this causes the
parent to always have a hard C# reference (from the child) as the child
is non-collectable due to the parent holding an Eo reference to it.
Depends on D8678
Test Plan: `ninja test` and `make test`
Reviewers: lauromoura, felipealmeida, woohyun, segfaultxavi
Reviewed By: lauromoura
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9014
2019-05-31 13:43:11 -07:00
|
|
|
static void
|
|
|
|
_dummy_part_holder_efl_object_destructor(EINA_UNUSED Eo* obj, Dummy_Part_Holder_Data *pd)
|
|
|
|
{
|
|
|
|
if (pd->one)
|
|
|
|
efl_parent_set(pd->one, NULL);
|
|
|
|
if (pd->two)
|
|
|
|
efl_parent_set(pd->two, NULL);
|
|
|
|
}
|
|
|
|
|
2019-05-22 13:21:02 -07:00
|
|
|
Efl_Object *_dummy_part_holder_efl_part_part_get(EINA_UNUSED const Eo *obj, Dummy_Part_Holder_Data *pd, const char *name)
|
|
|
|
{
|
|
|
|
if (!strcmp(name, "one"))
|
|
|
|
return pd->one;
|
|
|
|
else if (!strcmp(name, "two"))
|
|
|
|
return pd->two;
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#include "dummy_part_holder.eo.c"
|