One year later ... On Wed, 18 Jan 2012 21:26:55 +1000 David Seikel <[email protected]> wrote:
> On Wed, 18 Jan 2012 18:36:21 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > get onto irc and i'll explain... i feel i'm repeating myself. > > After repeating ourselves on IRC once more, we came up with a workable > plan that might make everyone happy. > > > First step is to write edje functions for generically bundling up one > or more Lua tables into a message, sending that message, then > unpacking it again. This will be able to be done from edje, from C, > and from Lua directly. Perhaps adding that as one more edje messege > type. This is for sending Lua tables between threads. A later > addition will be to send them through the 'net, probably as eet. > > Host apps can register arbitrary functions with edje Lua, using a more > generic version of the code I already wrote for letting edje register > lua functions. These host functions are by default not thread safe. > Edje puts a wrapper function around the host app, and registers that > wrapper function with Lua. The wrapper function, when called from > Lua, does this - > > ecore_thread_main_loop_begin(); > call the host app callback(); > ecore_thread_main_loop_end(); > > The first alternative, which the host app must request, is for the > wrapper function to use the table message functions to marshal the > arguments, send it to the main thread, wait for the response (or do > something else), then unmarshal the result before sending it back to > Lua. > > The second alternative, which the host app must REALLY request, is for > the host app to say "I'm REALLY going out of my way to be threadsafe, > just call me direct". No edje wrapper function, BUT the host app > still has to use edje to register this function. > > The first two might be done this way - > > host_cb = edje_lua2_functions_add(...); > edje_lua2_function_marshal_set(host_cb, function); > > The last one could be - > > host_cb = edje_lua2_threadsafe_function_add(...); > > Note the difference between _functions_ and _function_. The first > call registers an entire metatable full of functions, in the same way > that edje does for it's functions. These are the default sort of > functions. The second call references one of those previously > registered functions, and makes it marshal arguments and results. The > third one registers a single function, but it could be added to an > existing metatable registered by the first function. > > Comments? No one actually commented on this. I suspect that most don't care, and those that care figured raster and I had discussed it to death and came up with the right solution. Right now is time for me to consider starting to implement this. I'm looking at the design of the next step in my virtual world projects, and I think this will come in handy. That's why I was thinking about doing it before. Now it's time to put my money where my mouth is. I'll think about it some more, with respect to the virtual world stuff I want to implement now, and that I have already done. See if it still fits into my plans, and how to actually go about it all. Then I'll report here and get stuck into more Edje Lua code writing. > BTW, since in my current project I'll be writing code to use luaproc > for threading thousands of Lua scripts using worker threads and a > queue, I can probably incorporate that into edje Lua to begin with. This part has been done in that project I mentioned. What I actually ended up doing was to basically port luaproc to EFL. This allowed me to throw away more than two thirds of luaproc source code. Most of what was thrown away was just luaproc's own implementations of stuff that EFL implemented anyway. The rest was simplifying luaproc for my use case. If I remember correctly, Raster wanted to thread more parts of Edje. I might be able to bring this work into Edje Lua such that the Edje Lua scripts are threaded in a worker queue. When combined with the above table marshalling additions, plus using a few more things that have been added to EFL, I suspect I can get half of the remaining code to vanish as well. It's not a lot of code now, 15 KB. To top it all off, I'll likely be bringing my LuaJIT work to Edje Lua as well. Not sure yet how to go about that, but I think it would be preferable to have that as a compile time option. If LuaJIT is available, compile for it, otherwise compile for ordinary LUa. See my notes elsewhere for how much SPEEEEED LuaJIT brings. B-) -- 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
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
