On Wed, Jul 27, 2011 at 10:08 AM, Cedric BAIL <cedric.b...@free.fr> wrote: > > Hi, > > 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. 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 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 The downside is that the whole EFL needs to be rewritten... YET AGAIN :-D -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
