On Wed, 18 Jan 2012 19:04:06 +1000 David Seikel <onef...@gmail.com> said:
> Why does edje have to call the host callback from the thread when it's > perfectly capable of calling other callbacks from the main thread? to do that you have to marshall params and returns to the mainloop FROM the thread from lua and back again with a synchronous messaging mechanism. i mentioned that before. :) > > > > > 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. > > In this one case, which you seem to have forgotten, it does not matter, > coz it's a thread safe function anyway. In this case we are dealing > ONLY with a structure in the Lua state which is running in this same > thread, or dealing with structures that are only dealt with in this > same thread, or the thing is thread aware anyway and does the right > thing (probably coz it's doing it's own threaded stuff). In this one > case, doing things your way means that we suddenly complicate things by > calling them from some other thread, which is what you are arguing > against. get onto irc and i'll explain... i feel i'm repeating myself. > > > 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). > > So, what about the callbacks to Lua? When the Lua is running in some > thread coz we threaded edje, but edje calls it's resize function in a > different thread? edje wont. edje will turn it into a message. it's perfectly allowed to do this internally. there is no requirement for them to be in the same thread. > > > > > > 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. > > Sending a message has the overhead of at least two function calls, > four if you want information to come back. How is that more efficient > than one function call? messaging is less efficient than a direct call... but it SCALES. BUT it allows for us to thread edje. not doing messaging means we are stuck with lua running in the mainloop and i don't like that. we are paining ourselves into a corner because of laziness with doing messages. > I'm working on something right now that will involve Lua scripts > running on separate threads, that will need to communicate to stuff > running on other threads, and also just call functions on the same > thread. I'll have to figure out all the issues for this project > anyway. It uses eina for data structures, atd uses edje Lua only for a > test harness. The threaded Lua scripts in this project are not using > edje. > > This current project does lead into the one where I want to use this > functionality. It's the server side, so it already has to deal with > it's UI stuff by sending messages across the 'net. The next project > pretty much does lua for client side, and that's where I want to > embed more functionality in the lua scripts than just have them be > purely GUI. Having to split these client side Lua scripts in two just > seems silly. > > It's gonna get complex either way we cut it. Better to put that > complexity in the C code than in the Lua code. Better still to provide > a code path that bypasses the complexity when it just gets in the way. > > Or we could go the other way. Let Lua in .edc files be just the way > you want it, but allow .lua scripts to have the same edje Lua AND > WHATEVER ELSE THE HOST APP WANTS embedded in them. The code for that > would be almost identical, as I'd still want to reuse the helper > functions I've already put into edje, making them public and more > general purpose. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- 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
