On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel <[email protected]> > said: > > > If I remember, edje Lua puts everything into the Lua state, with no > > globals. So it should be threadsafe to start with. If not, it will > > have to be made threadsafe anyway when edje goes threaded. > > > > 1) > > > > The host function might deal purely with some data structure that is > > internal to the script. This means it's userdata (or perhaps just > > plain Lua data) attached to the Lua state. This should be > > inherently thread safe as per 0). This could be inefficient if > > dealt with via messages. > > it still violates efl's position of always calling back to the > mainloop. trust me - its HORRIBLE to call back from threads. it > really is. don't do it. In this particular case there is no worries, but see below. > > 2) > > > > That userdata in 1) might involve things that happen in other > > threads of the host app. Then it's up to the host app to deal with > > it's own threading problems. Not our problem. > > totally app issue. Exactly. > > 3) > > > > The host function might deal with EFL stuff. This is a case where > > it would be better to have more EFL API in the edje Lua, or use > > messages. Messages is a usual method in EFL anyway. So what we are > > doing already works for this case. > > that's our job to make al these extra helping apis then :) No worries. > > 4) > > > > The host function might deal with it's own internal data structures. > > This I think is the problem you see? If it's not a threadsafe host > > app, then things can go horribly wrong when host functions are > > unexpectedly called from some random edje thread. > > correct. > > > Wont the same problems happen when some host function EFL callback > > is unexpectedly called from some random EFL thread? > > it never is currently. adding your externally provided lua functions > will STOP us from being able to put lua execution into a thread. it > will always have to be inline in the mainloop and that is a big > limitation. > > messaging solves this problem. > > > So the same solutions could be used. Host API functions are really > > just another callback system. The host registers it's callbacks > > with edje Lua, edje Lua calls them back. Why is this different > > from the rest of EFL using registered callbacks? > > 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. > my problem is that by making lua extensible by functions provided > from the app, these functions must, by efl convention, be called from > the mainloop and thus you must implement them as synchronous ipc (if > we add threads) thus you have to marshall/unmarshall params/returns > down pipes. if you are going to do this you shoudl just do it all to > begin with that way and simply have the write/read right next to > eachother. Or get the Lua call to go through EFL as I mentioned above. That's the safe callback register method for most host app functions. 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. > 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 -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
