On Thu, 28 Jul 2011 12:45:14 +1000 David Seikel <onef...@gmail.com> wrote:
> On Wed, 27 Jul 2011 15:08:21 +0200 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). > > I agree with Cedric to disagree, purely on principle. Er, meaning I > disagree with this patch. > > > > the performance cost and complexity is easily outweighed by the > > > benefit of meeting developer expectation. > > That's the slippery slope that lead to most of todays software being > so bloated. > > /me stops his early morning rant and gets breakfast. OK, now that I'm awake, and had brekky... Ah, thread SAFETY. Some amount of thread safety is OK so long as it does not impact on the other core values in general. Speed and lightness should be the hallmarks of EFL. So long as those are achieved, and it just happens to be thread safe to, then all is good. Still should just tell people that thread safety is not guaranteed, and hardly needed. -- 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
------------------------------------------------------------------------------ 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
