Oops, forgot to CC the ML. ---------- Forwarded message ---------- From: Cedric BAIL <cedric.b...@free.fr> Date: Thu, Jul 28, 2011 at 12:13 PM Subject: Re: [E-devel] [PATCH] ecore: Add basic thread safety To: Gustavo Sverzut Barbieri <barbi...@profusion.mobi>
On Wed, Jul 27, 2011 at 9:18 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Wed, Jul 27, 2011 at 10:08 AM, Cedric BAIL <cedric.b...@free.fr> wrote: >> On Wed, Jul 27, 2011 at 1:17 PM, Mike McCormack >> <mj.mccorm...@samsung.com> wrote: >> > This patch adds some level of thread safety to ecore. >> > It does not add thread awareness (i.e. adding a timer from a thread will >> > not >> > wake a sleeping main loop). >> >> So it will most of the time work, but in some racy case, not. Sounds >> to me like this doesn't change much from the current behaviour. I >> agree, it will work more often than previously, but still hidding bug >> until it's to late. >> >> > In my experience, developers either are ignorant of the problems of >> > threads, >> > or expect libraries to magically work with threads. >> >> People should never use things they don't understand... and so few >> people understand threads. Just one question, do they use ecore_thread >> or there own stuff ? >> >> > I understand that some people think that thread safety is not necessary, >> > but >> > IMO, the performance cost and complexity is easily outweighed by the >> > benefit >> > of meeting developer expectation. >> >> You can't make it work sanely, how are you planning to synchronize the >> rendering state with your request from a thread. It's just not >> possible, you are adding stuff to make it work more often, but that's >> not thread safety and will lead to more complex issue to debug in the >> futur. I would prefer that we advocate the use of ecore thread and use >> eina thread debugging property to prevent efl call from outside of the >> main loop by either asserting, displaying a backtrace or just spanking >> (stuff that could turned on and off at compile time and help provide >> development build or production build). >> >> I clearly disagree on that patch going in (and I am still not >> discussing the issue of performance here). > > Cedric, I disagree with you and agree with Mike. > > Let's face it, we pushed threads away for years, it did not help. > People won't learn (precious time) and they'll just use it incorrectly > or get away from EFL at all. Mike is only trying to minimize parts of > the problem... and in an real world application there should be enough > activity on the main thread to make this problem not happen at all. > Alternatively we can have a FD on own own and write to it whenever we > added stuff from worker threads. If you really want that feature, we should do it right. So use one Ecore_Pipe with lock around it on writing, and write a duplicate of the command to it when not in the main loop and call the command from the main loop. At least that would work in all case and wont trigger any bug. > All in all I'd use the Evas rewrite Raster wants to do and think about > it as well. I know it's a tremendous effort, but likely if we design > things like that we can achieve always thread safe GUI. I'm not > talking about locking all the paths and render immediately, we can > take a simpler path to serialize access to each object and do the > actual work from other threads. > > IMO the perfect solution would be: > - PROCESS: image loading process, no loading would be done in the > application process. Data would always be shared with shmem > - THREAD: garbage collector & defragmenting for our datatypes. > - THREAD: evas rendering > - THREAD: ecore mainloop Evas rendering will use multiple thread and not just one, it will also use multiple process and will get out of the main loop quickly. > Given N applications we'd account as: (1 + N * 3) threads. Given > stupidly cheap Linux threads this is not a performance impact. The > benefits are clear: > - application would never block to users > - image data would be shared among applications (themes, etc) > - we'd avoid memory fragmentation and most of the leaks Agreed, that's also how I see things (was planning to use Ecore_Thread in edje for garbage collection/free loop), but that doesn't put any requirement on the EFL to be thread safe. And that's my main point, take evas as an example, if you push to make it's call thread safe, and do an evas_object_move followed by an evas_object_resize. How are you sure that they the change will be synchronized and happen in the same frame ? You need to add some kind of synchronisation barrier explicitly in your code to be sure that all the object you wanted to update will be updated at the same time. And this should work on all thread at the same time, I don't see how you can make it work. From my point of view, if you want thread, use ecore_thread, we have yet some that can send feedback during their live to the main loop and simple worker one. I have started locally working on more complex use that can directly trigger a function call in the main loop or in any thread from any thread. Then application just need to call EFL function in the main loop callback (that are easily triggered from the thread) or face spanking. Eina does provide the identity of the main loop thread and should be used to warn user when they do something wrong and point them to Ecore_Thread facility. > The downside is that the whole EFL needs to be rewritten... YET AGAIN :-D Yeah, time to borke svn again ! -- Cedric BAIL -- Cedric BAIL ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
