On Sun, Jan 8, 2012 at 12:46 PM, David Seikel <[email protected]> wrote: > On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > >> On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel <[email protected]> >> said: >> >> > I just woke up, first email for the day. Not quite grasping why >> > this will be any different between edje Lua API and random host app >> > Lua API. They still both gotta be threadsafe when we thread >> > things. Random host app, being an EFL app, would have to be >> > threadsafe if EFL is threaded. >> >> incorrect. if efl is threaded host ap does not need to be threadsafe. >> that is my point. such a requirement would be onerous and wrong as >> the host doesnt know if edje is threaded or not. it shouldn't need to >> know. >> >> > The Host API stuff will go through the edje Lua API to do it's >> > thing, and the edje Lua API will have to be made threadsafe, so any >> > other thread issues will be the host apps plobrem. Just like apps >> > using the rest of EFL. >> >> thats not the issue - its that the call from lua (in edje) to host >> app happens directly as a function call, thus is lua is running as a >> thread, the call in host spac happens inside a thread created by >> edje. this is unacceptable. it must be MARSHALLED back to the >> mainloop - thus synchronous ipc calls. >> >> > Hell, the projects I'm working on now that need this host API stuff >> > have to be threadsafe anyway. One of the design goals is to be >> > able to run thousands of scripts at once safely and quickly, while >> > the rest of the world code is busy chugging along. That's why I'll >> > be experimenting with luaproc ansd LuaJIT. >> >> well this isnt really about your apps - but the general case - if its >> a general api made available, then the calls TO the host app must >> happen in the main loop context (thread) not another. all things must >> be marshalled back to the mainloop. thus why the messaging/signal api >> is much better here as it is a messaging api, not a call api. > > I understand now, I think. > > The host app itself may be multi threaded, so we do need to cater for > this. We also have to cater for those cases where it does not matter, > and those cases where a messaging API is a bad choice. We would have > to make sure that edje Lua itself is threadsafe first. > > 0) > > Lua scripts themselves can be run on different threads, it all happens > via the Lua state, which is just a pointer to everything. luaproc is a > system of running lots of scripts in worker threads, where each worker > thread peels the next ready Lua script of the ready queue, runs it > until it yields, then slaps it on the bottom of the run queue. I'll be > experimenting with that soon. > > 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. > > 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. > > 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. > > 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. > > Wont the same problems happen when some host function EFL callback is > unexpectedly called from some random EFL thread? > > 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? > > Only 4) is a problem, unless I've missed a use case? Please add more > if I did. > > > > BTW, I brought up my apps as it WILL be dealing with thread issues. So > it might make for a good test of my proposed addition. Without my > addition, people writing scripts for my apps will have to write two > scripts, one that deals with the GUI, and sends messages to the other > one. Considering some of my hard limits on this project (existing > stuff I have to work with, this is not being designed from scratch), > that's not acceptable for me. I'd have to come up with something else, > and not use edje Lua.
Short answer and just guiding to EFL thread infrastructure. As you are using some kind of bindings, it is possible to call ecore_thread_main_loop_begin and ecore_thread_main_loop_end in the right place. Be aware this could impact your performance if you don't group them. -- Cedric BAIL ------------------------------------------------------------------------------ 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
