celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Event admin patch
Date Tue, 01 Apr 2014 08:00:45 GMT
Hi,



On Mon, Mar 31, 2014 at 7:16 PM, Erik Jansman <Erik@jansman.eu> wrote:

> Hello Everyone,
>
> I have been working on the changes for a while now. My current local
> version has the moved event owner ship and a change in how the channels are
> stored. I'm close to finishing that bug. Should I commit the changes I have
> so far or finish the Async first?
>

I prefer that you the commit the changes so far and add some issue for the
known short comings. This also makes it easier for us to comment and/or add
changes to code. Use the SET_HEADER(BUNDLE_VERSION, ...) to make it clear
that is not a complete event admin yet.

Greetings,
Pepijn



>
> Regards,
>
> Erik
>
> On 28-1-2014 19:49, Pepijn Noltes wrote:
>
>> Hi Erik,
>>
>> On Sun, Jan 26, 2014 at 7:55 PM, <erik@jansman.eu> wrote:
>>
>>  Hello,
>>>
>>> I'm sending an updated version of the event admin. I have renamed the
>>> methods to follow the standards. I have moved the event admin into the
>>> celix folder like the other subprojects.
>>>
>>> Known issues:
>>> 1: The async sending isn't implemented yet.
>>> 2: At this moment the event publisher is owner of the memory for the
>>> event. This is probably not the best solution for the async sending.
>>>
>>> I would like to propose a change to the Event admin and move the event
>>> implementation to the event admin. This would make the event admin owner
>>> of the memory.
>>>
>>> Would this be a good choice or is there another solution?
>>>
>>>  I think this is a good choice. The event admin knows when all sync/async
>> event handlers have been called and as result when the event can be
>> deleted.
>> IMO the event admin API should contain a create for the event and clearly
>> states that is will also free this event when all event handlers have been
>> called. The event admin should free the event and its properties, but it
>> should clearly state that it cannot and will not free complex (e.g.
>> strings, or pointers to structs) values of the event properties.
>> For now that is IMO enough, but in eventually we probably also need a
>> callback to that the owner of the complex values of the event properties
>> can delete those.
>>
>> There is of course always another solution ;) Anybody any better/different
>> ideas?
>>
>>
>>  Regards,
>>>
>>> Erik
>>>
>>>
>>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message