On 27/07/13 03:10, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
> <lucas.demar...@profusion.mobi> said:
>
>> On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>>> On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>>> <barbi...@profusion.mobi> said:
>>>
>>>> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen <tom.haco...@samsung.com>
>>>> wrote:
>>>>> On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>>>>>> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher <jer...@asynk.ch>
>>>>>> said:
>>>>>>
>>>>>>> just to clarify a few points:
>>>>>>>
>>>>>>> - I think the less macro we have in an eo class declaration the best,
>>>>>>> actually we have nothing but that extra first parameter called
>>>>>>> eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx
>>>>>>> (devs/jeyzu/eo2)
>>>>>>>
>>>>>>> this should go away if we use a stack per thread in eo private code,
>>>>>>> so we end up with a clean
>>>>>>> EAPI float times(float f, float t);
>>>>>>>
>>>>>>> - since day 1 break is supported in eo2_do:
>>>>>>> #define eo2_do(obj_id, ...)
>>>>>>> do
>>>>>>> {
>>>>>>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>>>>>>> if(!obj_ptr_or_ctx) break;
>>>>>>> do { __VA_ARGS__ ; } while (0);
>>>>>>> eo2_do_end(obj_ptr_or_ctx);
>>>>>>> } while (0)
>>>>>>
>>>>>> i'm worried about people doing return there. seriously - objid came in
>>>>>> becau se of experience that people using efl are in general
>>>>>> inexperienced programmers who don't take the time to do things right.
>>>>>> they do things quickly and take shortcuts, and they ignore warnings.
>>>>>> they'd rather patch out abort()s in efl code forcing them to fix their
>>>>>> bugs, than fix their bugs. i am fearful that they will stuff in returns
>>>>>> quite happily and think it mostly works most of the time... and then
>>>>>> find subtle issues and waste our time finding them.
>>>>>>
>>>>>> how do we protect/stop returns (or goto's for that matter) within the
>>>>>> while block. i looked for some pragmas - can't find any to do this.
>>>>>> this would be a really useful compiler feature though (to maybe disable
>>>>>> some constructs for a sequence of code).
>>
>> What you seem to be looking for is the cleanup attribute.
>>
>> #define eo2_do(obj_id, ...)
>> do
>> {
>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> if(!obj_ptr_or_ctx) break;
>> do
>> {
>> obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
>> dummy = obj_ptr_or_ctx;
>> __VA_ARGS__ ;
>> } while (0);
>> } while (0);
>>
>>
>> But then we need to take a look if the cleanup function will run when
>> the actual function returns, or when the second "do" runs out of
>> scope. This attribute is more commonly used to call free on the
>> variable, so it doesn't matter much.... but for us this would make a
>> difference if it involves locking.
>>
>> Then you just allow break and return, and the right thing will happen,
>> even in those cases.
>
> voila! that would do it (if it does work on return as well as break and any
> goto that jumps out of the while scope). if course it'd be dependant on
> compiler supporting it - if it doesnt, then we cleanup by hand as normal on a
> break and return/goto just create bugs. i'd be ok with that. need to add
> -fexceptions maybe too from a quick read. needs a little experimenting and
> some
> method of detection. looks like its single parameter only and i guess it is
> done variable by variable which is good enough for us. :) i wonder how new it
> is. hmm looks like gcc 3.3 - that means it's rather old by now. GOOD. i hope
> clang supports it too and.... it seems not. :( oh well. let's hope most devs
> still use gcc. :)
>
>
Btw, just to clarify something.
It will not only result in a reference leak, it'll also make things go
really nuts. Consider the following scenario:
You call eo_do on object A, and then from *inside* of the first call,
you call eo_do on object B. If in the call on object B you have a
return/break on windows, you'll keep the global context stack set on B,
and then you'll end up calling the rest of the calls in the first eo_do
on object A because of B. Really bad. Obviously will only happen on windows.
Two things we still need to sort out:
1. Call eo_do_end on platforms that don't have this attribute.
2. When we pop from the ctx stack (i.e eo_do_end) we should consider
matching against the object id to verify we actually popped the correct
one and print an error otherwise.
--
Tom.
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
