On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher <[email protected]> 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).
> - EAPI static inline func() and overriding worked
> untill I used eapi symbol address instead of OPID
> it's a 2 hops game: EAPI func() { f = eo2_get_real_func_ptr(OPID, OBJ);
> return f(OBJ, OBJ_DATA, _args_) };
>
> is it ok for everyone to forget about EAPI static inline ?
as long as the method the programmer sees is
method(p1, p2);
NOT
method(obj, p1, p2);
:) (ie its wrapped in a macro)
> On Monday 22 July 2013 14:45, Carsten Haitzler wrote :
> > On Mon, 22 Jul 2013 10:24:03 +0900 Cedric BAIL <[email protected]> said:
> >
> > > On Mon, Jul 22, 2013 at 8:55 AM, Carsten Haitzler <[email protected]>
> > > wrote:
> > > > On Sun, 21 Jul 2013 15:18:02 +0200 Jérémy Zurcher <[email protected]>
> > > > said:
> > > >> Hello from my holiday in France (for the frenchies who know lofofora ;)
> > >
> > > Enjoy !
> > >
> > > >> On Friday 12 July 2013 15:42, Carsten Haitzler wrote :
> > > >> > On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen
> > > >> > <[email protected]> said:
> > > >> >
> > > >> > ok. looked at eo2test.c
> > > >> >
> > > >> > eo2_do(obj,
> > > >> > a = inst_func(eo_o, 32);
> > > >> > inst_func(eo_o, 10);
> > > >> > b = inst_func(eo_o, 50);
> > > >> > );
> > > >> >
> > > >> > first... passing in eo_o... should probably go away. ie
> > > >> >
> > > >> > eo2_do(obj,
> > > >> > a = inst_func(32);
> > > >> > inst_func(10);
> > > >> > b = inst_func(50);
> > > >> > );
> > > >>
> > > >> the declaration is
> > > >> EAPI int inst_func_set(eo2_a, int a, int b);
> > > >>
> > > >> expanded to
> > > >> EAPI int inst_func_set( _Eo *obj, Eo *objid, int a, int b);
> > > >>
> > > >> what I first proposed was using a second macro
> > > >> eo2_do(obj,
> > > >> sum = eo_call(inst_func_set, 32, 12);
> > > >> a = eo_call(inst_func_get_a);
> > > >> );
> > > >>
> > > >> would it be better ?
> > > >> (Tom, I don't love it, that's just handy ;)
> > > >
> > > > i dont see why? make inst_func() a macro that defines to inst_func_real
> > > > (__cur_obj, ...) eo2_do() defines a local var for __cur_obj when obj is
> > > > looked-up (so lookup happens only once per do block).
> > > >
> > > >> > secondly, having a = xxxx; with ; too.. is going to start encouraging
> > > >> > people to do really bad things like:
> > > >> >
> > > >> > eo2_do(obj,
> > > >> > if (inst_func(32) != 22) return;
> > > >> > inst_func(10);
> > > >> > b = inst_func(50);
> > > >> > );
> > > >> >
> > > >> > and all sorts of hell is going to break loose here. i don't believe
> > > >> > that as a result of returns we can now sensibly handle method errors
> > > >> > from an eo_do() batch. if we are using returns for errors we SHOULD
> > > >> > have something like:
> > > >>
> > > >> well the rule is really simple to document and explain:
> > > >> use break not return in e eo2_do() construct
> > > >
> > > > next problem. if we ref() on do start and unref() on end of do... this
> > > > just broke it. any form of breaking out will break stuff badly (break,
> > > > return, continue).
> > >
> > > Not break. It is easy to make it work without using macro. We just
> > > embedded it into a do { } while (0); loop and the break will work just
> > > fine. The problem will be that the semantic of continue will not be
> > > related to a loop where eo_do is running, but to eo_do code itself. I
> > > would just strongly advise in the documentation to not use those
> > > trick.
> >
> > we need 2 do {} while's then... :)
> >
> > > >> > Eo_Err err;
> > > >> >
> > > >> > err = eo_do(obj,
> > > >> > a = inst_func(32);
> > > >> > inst_func(10);
> > > >> > b = inst_func(50);
> > > >> > );
> > > >> > if (err.error == inst_func1_id) return; // inst_func1 method id is
> > > >> > what failed
> > > >>
> > > >> we have no more function id in the latest prototype,
> > > >> but this disallow EAPI static inline func();
> > > >>
> > > >> I'm waiting for comments from Tom and others about this.
> > > >
> > > > static inline is incompatible with things like method overriding at
> > > > runtime anyway :) but still... imho the "now we have returns we can get
> > > > errors" is a bogus claim, because of the previous point... you can get..
> > > > but you cant DO anything useful (return, break, continue)... UNLESS you
> > > > provide a macro that cleanly aborts the do block (example - #define
> > > > eo2_break() _eo_unref(__cur_obj); break). i was just showing how errors
> > > > could be done very simply with the current eo api by returning an eo_err
> > > > struct, rather than a single bool.
> > > >
> > > >> > if (err.failedop == 2) return; // in a batch, operations are
> > > >> > counted, 0, 1, 2 // so op id 2 (last one) failed here
> > > >> > if (err.type == EO_ERR_INVALID_VALUE) return; // can put err inside a
> > > >> > type field.
> > > >> >
> > > >> > note that this is using an error return as a struct, not a basic type
> > > >> > (int, pointer, char, etc.), and this is perfectly valid and correct
> > > >> > in basic c. it's not an extension. we COULD pass in a ptr to the err
> > > >> > struct too instead of using a return.
> > > >> >
> > > >> > but... in the end the error is returned and deal with OUTSIDE of the
> > > >> > eo_do() block. so we guarantee to always exit the eo_do() block at
> > > >> > the end safely and handle refcounts properly. if people start putting
> > > >> > arbitrary code inside the block with returns and what not.. compilers
> > > >> > will allow this in eo2... and we will have problems. big ones. i can
> > > >> > smell it right now. so i'd say dont allow ; s and arbitrary code
> > > >> > inside. use , i.e.
> > > >> >
> > > >> > Eo_Err err;
> > > >> >
> > > >> > err = eo_do(obj,
> > > >> > a = inst_func(32),
> > > >> > inst_func(10),
> > > >> > b = inst_func(50),
> > > >> > );
> > > >> >
> > > >> > ... needs some looking into maybe ...
> > > >>
> > > >> what does 'guarantee' and 'don't allow' mean ? I think no more than
> > > >> words in an API doc. if users want to try wrong construction they
> > > >> still will be able to. (sure eo_do() is stronger in that case,
> > > >> compiler does not accept code in varargs !!) So what matters is which
> > > >> one is the simplest to use and to document. for me it's clearly 'do
> > > >> not use return' btw what users and us will do is not much than eo2_do
> > > >> (obj, ret = eo_call(do_some, 133, 254);
> > > >> if(!eo_call(try_this,435)) break;
> > > >> ret = eo_call(all_perfect);
> > > >> );
> > > >>
> > > >> no need to explain users how to handle the error code, no need for us
> > > >> to waste precious time checking last call status to know if we must
> > > >> break eo2_do (…)
> > > >
> > > > break kills the ref/unref pairs... (we ref so any calls that may
> > > > directly or indirectly delete an object inside don't cause the rest of
> > > > he ops to crash and obj is cleaned up then at the end of the do block).
> > >
> > > Not in that case, no problem there ! :-)
> > >
> > > >> > my other reservation is that e are exposing the pointer to an eo obj
> > > >> > TO the application code.. and the objid stuff in eo was to try
> > > >> > isolate this. this now leaks it out into the app... allowing for
> > > >> > abuse and misuse. that is a downside of this.
> > > >>
> > > >> yes, I too dislike this, but don't think this is that harmfull.
> > > >> it's an opaque type, what could users do with it, free it ??
> > > >> bloody bastards may the gods punish them I'would say!
> > > >
> > > > well it's more that it's now within the stack frame of a caller func.
> > > > that means its there... the minimum we should do is set it to NULL at
> > > > the end of the do block so they can't see it.
> > > >
> > > >> btw I tried to use an object context instead, see devs/jeyzu/eo2
> > > >> it looks like this (eo2_do() expanded):
> > > >> ctx = eo2_do_start(obj_id);
> > > >> my_eapi_func(ctx, args);
> > > >> ...
> > > >> eo2_do_end(ctx);
> > > >>
> > > >> the goodies are:
> > > >> - no more object pointer leaking in user land
> > > >> - detect a missing eo2_do_end() on the next call to eo2_do_start()
> > > >> - cache the object data pointer
> > > >>
> > > >> ctx is not thread safe but could be
> > > >
> > > > ultimately we'd have to make it threadsafe. as long as ctx is hidden
> > > > from the user code and they dont have to keep typing it in... :) the
> > > > problem now comes with making this threadsafe and not hurting
> > > > performance-wise. with the current eo_do() we can just mutex lock() and
> > > > unlock() objs on entry to eo_do() and on exit of eo_do(). ... stack of
> > > > course inside eo is private per thread so we're good. to avoid locks on
> > > > ctx it'd have to use thread local storage - and then that begs the q...
> > > > what to do when that thread is ended? how to delete tls?
> > >
> > > Using lock should not impact speed to much, but we have benchmark to
> > > test that, so let's see !
> >
> > taking a lock does cause some overhead... i remember reading:
> >
> > http://surana.wordpress.com/2009/01/01/numbers-everyone-should-know/
> >
> > i know.. taking a blog at its word without actually testing yourself is
> > silly, but a mutex lock/unlock is about a cost of an l2 cache miss. :)
> > that's not "free". :) i assume this is also a futex as opposed to an actual
> > contended lock which will require a syscall to the kernel... (or a spinlock
> > wait... ewwww)
>
> for now, Call_Context is a static struct in eo.c
> initialized by eo2_do_start() end cleared on eo2_do_end()
> malloc/free costs too much, I don't know about eina_mempool ???
>
> I was more thinking about gettid() and a Call_Context struct per thread.
> do we really need to lock objects, what is or will be thread safe in efl ?
i think we need to lock them - specifically because at some point we will want
some objects threadsafe and others not. it could be an object option i guess...
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler) [email protected]
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --- Hell'O from Yverdoom
>
> Jérémy (jeyzu)
>
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
