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