On Wed, 18 Jan 2012 15:47:43 +1000 David Seikel <onef...@gmail.com> said:
> On Wed, 18 Jan 2012 11:30:55 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Mon, 9 Jan 2012 00:18:38 +1000 David Seikel <onef...@gmail.com> > > said: > > > > > On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman) > > > <ras...@rasterman.com> wrote: > > > > > > > On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel <onef...@gmail.com> > > > > said: > > > > > > > > > > because all the other callbacks come from code controlled by efl. > > > > lua funcs come from code (script - lua) not controlled by efl. > > > > > > The host app callbacks would be setup by edje Lua on behalf of the > > > host app (that was always my intention). So the edje Lua can > > > register a wrapper function that it controls. Lua calls the > > > wrapper function, which lets edje Lua decide what to do. So it > > > becomes just like the other EFL callbacks, EFL is in control. > > > > yes - BUT it's called FROM a thread because LUA calls the registered > > func. it has to be marshaled back to the main loop in a synchronous > > way. > > LUA calls the registered function that is registered by edje, not the > one registered by the host app. Edje then calls the host apps > callback. Exactly the same as any other callback in EFL. It's no > different. yes - i know... and edje then calls the func registered by app and THUS its inside the thread that lua is running in. its VERY VERY VERY VERY different. the function is being called FROM a thread... and that means all child funcs are in that thread's context, on that threads stack. > > > I'd still want an additional ability to register a type 1) function > > > to just call back on the same thread. It would come with lots of > > > documented warnings that it will screw things up in mysterious ways > > > if used the wrong way, but then so does a lot of EFL. With power > > > comes responsibility. > > > > i really don't like this as it is unknown if it is called form a > > thread or not (depends on edje version). > > This is for the case where IT DOES NOT MATTER if it's called from a > thread or not. Such cases do exist, and they are far more efficient to it absolutely matters 100%. it is irrelevant how many functions u sandwich between app and lua - if they are called on the thread's stack in the thread context, then that is bad. your proposal means that we cannot thread edje's internals, or we have to make threaded and non-threaded codepaths (more maintenance and bugs) and thus force all edje objects with lua that u register exposed funcs to to never run in a thread - thsu complexity. > just call the function direct. It comes with a big warning, and if > it's not used right, then the programmer gets spanked. We can't > protect programmers from all their foolishness. I don't think we > should straight jacket them for their own protection. we can't just start making magic function callbacks that may or may not be called from threads - it breeds inconsistency in the api and it is a very core feature that you want here. > We provide enough protection for the Lua programmers, it's the C > programmers that are registering these callbacks, they know how > dangerous their language is and deal with it all the time. no callbacks in any of efl (except the ecore_thread functions that are run in a thread or the elm_store func that is run in a thread very specifically) are called from a thread. it is a guarantee that efl has. in fact from that thread u couldn't call any edje or evas calls as they are not threadsafe. every other callback in efl is safe in this regard (except for the very specific exceptions above because both are very specifically designed to be in threads, but the function exposing you propose are not specifically threaded). > > > > this of course will add overhead to this. async messages are much > > > > more desirable as they allow both sides to not block. :) > > > > > > ONLY using messages is very undesirable from my point of view. I've > > > seen the mess they can do when just a simple function call is > > > needed. Messages have their uses, so do function calls. I want me > > > cake and eat it to. lol > > > > but messages provide the best abstraction for also allowing > > efficiency and 2-way communication. > > Message passing is not more efficient than direct function calls. > Sometimes you need those direct function calls. its LESS efficient, especially if you do it synchronously between 2 threads. > I program in LSL, where you have to do this sort of message passing all > the time. Trust me, sometimes you don't want to mess with that > complicated shit, you just want a simple, fast function call. but that creates a problem for edje - a big one. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
