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. -- 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
------------------------------------------------------------------------------ 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
