On Tue, 17 Dec 2013 08:26:52 +1000 David Seikel <onef...@gmail.com> said:
> On Mon, 16 Dec 2013 22:45:30 +0100 dumblob <dumb...@gmail.com> wrote: > > > > Just as a point of interest, my experiments with using LuaJIT in EFL > > > > > found that the Lua stuff itself is threadsafe so long as we use a > > > thread safe memory allocator, which LuaJIT itself provides. The > > > memory allocator we currently use in Edje Lua is not thread safe. > > > I've been meaning to ask, do we have a threadsafe memory allocator > > > in Eina? > > > > > > You are correct though, the rest of EFL is not as thread safe. My > > > LuaJIT experiments involved enough message passing to deal with the > > > "marshall all your bob calls back to the mainloop" you mentioned. > > > > > > > Well, it doesn't sound that bad. Did you mean the sentence """My > > LuaJIT experiments involved enough message passing to deal with the > > "marshall all your bob calls back to the mainloop" you mentioned.""" > > like you've done enough message passing testing to rigorously state > > the only problem with Edje is its thread-unsafe memory allocator? > > > > -- Jan Pacner > > My experiments mostly concentrated on using EFL and LuaJIT to run many > thousands of Lua scripts at once, using a message passing technique for > communication between them. As I'm the main author of the current Edje > Lua system, a secondary goal was to see how well my results could be > used for Edje Lua, which doesn't currently use LuaJIT. > > The basic "run thousands of Lua scripts at once using message passing > for communications" part was based an an academic paper and the open > source code that went with it. I modified their source to make it EFL > based. It uses a worker thread system that pulls ready scripts from > a queue. Typically a script is ready when there is a message available > for it. > > I then incorporated the result into a LSL scripting engine. LSL is > Linden Scripting Language, which was invented by Linden Research for > their Second Life virtual world platform, and also used in OpenSim, an > open source clean room implementation of the Second Life server > software. It's an event based system. My version of the engine > converts LSL scripts into Lua, compiles that, then runs them in the > worker thread system. Using the message passing to deal with events. > Typically a "sim" (the basic unit of virtual land) would have > many thousands of LSL scripts running at once. > > While doing this I did compare usage of the memory allocator that comes > with LuaJit and the EFL one we are using in Edje Lua. The EFL one we > used is not thread safe, the LuaJIT one is. > > I've also had long discussions on this list with raster about future > plans for Edje Lua, including BOB. This is what led me to believe that > the message passing system I have been experimenting with would be > suitable for dealing with marshalling Edje and Evas calls back to the > main loop. We also discussed various other options for thread safety in > Edje Lua. I've not done any rigorous testing of this part of the plan, > but it is on my TODO list. Certainly BOB has no code yet, it's a > future plan. It's hard to rigorously test non existent code for a > future plan. > > In the end, what raster said is true, out of all the EFL C API, only > some is thread safe. The EFL design does include mechanisms for > marshalling unsafe calls to the main thread. So it doesn't matter which > scripting language is used to wrap it, somewhere along the line this > call marshalling will have to be taken care of. My intention with Edje > Lua is to make that transparent to Lua scripts. that's the idea. threads in bob will be a new LuaL per thread - some kind of pool - exactly as your experiment. they can do whatever they want but only access a subset of bound apis from efl. they can do whatever it is they need to do and then when done - maybe "send a table" to the mainloop for handling. this would be a result of all their work that the mainloop then applies/implements. this means you keep state changes in a single place (main loop), but can farm off work to threads and other cores when/if needed. you just have to decide if the cost of marshalling/unmarshalling/passing is significantly less than the actual work to do. if it is not, then chances are this kind of setup just hurts rather than helps. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
