On Mon, 22 Jul 2013 10:24:03 +0900 Cedric BAIL <cedric.b...@free.fr> said:
> On Mon, Jul 22, 2013 at 8:55 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Sun, 21 Jul 2013 15:18:02 +0200 Jérémy Zurcher <jer...@asynk.ch> 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 <tom.haco...@samsung.com>
> >> > 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)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
