On Thu, Nov 4, 2010 at 5:26 PM, Mike Blumenkrantz <m...@zentific.com> wrote:
> On Thu, 4 Nov 2010 12:00:32 -0500
> Mike Blumenkrantz <m...@zentific.com> wrote:
>
>> On Thu, 4 Nov 2010 09:42:55 -0700
>> "Enlightenment SVN" <no-re...@enlightenment.org> wrote:
>>
>> > blah blah commit blah blah
>>
>> This library, aptly named by Tom Hacohen aka TAsn who has demanded that I
>> give him all credit, exposes a serious bug in ecore 100% of the time through
>> my tests: the duplication of events.
>>
>> To demonstrate, simply compile and run 'make check' to compile the
>> additional tests. Then run src/tests/server (must be run from src/tests) and
>> src/tests/client. In the output of the client, you will see something like
>> this at the bottom:
>>
>>
>> DBG<17405>:azy azy_client_events.c:151 _azy_client_handler_data()
>> (handler_data=0x9ab2900, method='TTest1.getBigArray', ev=0x9b179f0,
>> data=0x9b17a00) (~15 other lines...) DBG<17405>:azy azy_client_events.c:151
>> _azy_client_handler_data() (handler_data=0x9ab28d8,
>> method='TTest1.putBigArray', ev=0x9b179f0, data=0x9b17a00)
>>
>> Note the pointer addresses for ev and data in these lines. While some other
>> events may have the same addresses, they are not the same data. This is not,
>> however, the case for the final pair of events. The data is identical.
>> Additionally, this final event IS NOT EMITTED. To see what I mean, run the
>> client in gdb with breakpoints/printfs at ecore_con.c:1786
>> (ECORE_CON_EVENT_SERVER_DATA event is ONLY emitted here in this app) and
>> _azy_client_handler_data. You will notice that every occurrence of
>> _azy_client_handler_data has an event right before it except for the final
>> one. This is a bug.
>>
> Okay, I have found the bug. If, in your event handler callback, you add
> another handler for the same event type, the current event will be passed to
> that new handler as well. My use case is that I am deleting the current
> handler and adding a new one during an event, so I do not want the same event
> to be passed to the new handler. Is this something that should be fixed in
> ecore, or something that I should be working around in my own code?
17:38 discomfit> I could fix it in ecore by counting the number of handlers
before I start running them, and stopping after I reach that
count
17:39 discomfit> can't really think of a good way to handle it outside of ecore
17:39 discomfit> the purpose of doing this is to switch data associated with
the handler
17:39 discomfit> since there is no event_handler_data_get/set
17:39 discomfit> you have to delete and recreate handlers
17:40 discomfit> which is horribly inefficient, but whatever
17:40 antognoll> i like both ideas (ev. handler count and
event_handler_data_get/set)
17:41 antognoll> why don't you put these ideas in the ML?
17:41 discomfit> why don't you do it so I don't have a thread where I'm
replying to myself
So, I like the idea of having this setter/getter and also fixing the
wrong handling of events (not for this case, but would be good to have
the correct behavior for this).
Anyone against that?
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
