Hi,
On Mon, Mar 31, 2014 at 7:16 PM, Erik Jansman <[email protected]> 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, <[email protected]> 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 >>> >>> >>> > >
