On Wed, 27 Jul 2011 15:08:21 +0200 Cedric BAIL <cedric.b...@free.fr> said:
OK... quick comments: 1. adding threadsafety isnt bad. it's no worse than the thread checks NO ONe complained about. it's also optionally enabled, so i see no downside there. 2. yes - it's a pain in the butt to do, BUT if someone is willing to do it... should we say no to someone picking up the work and doing it? 3. thread safety doesnt fix thread awareness. lets remember that. that's a different problem to fix and a separate topic. right now we hsave no official way to "wake up the main loop" when u do things like add a timer in a thread - if ecore is threadsafe. you can create a mechanism via ecore_pipe - but a simpler one would be needed eventually. until it's ready and well tested we can still claim ecore is not threadsafe. so.. now to specific comments. > 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. yes - it's not a final fix, then again how many things do we have in svn that get put in in stages. :) this doesnt finish making ecore threadsafe. it hasn't had a lot of testing yet. :) > > 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 ? they understand ecore_thread even less unfortunately. they also DONT understand ecore is NOT threadsafe. :( i sure as hell wasn't into the idea of making ecore threadsafe. i dont want to do the work. most here don't, but if someone is willing to do the work.. why should be veto it? > > 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 well that requires evas be threadsafe and edje and elementary ... etc. - they are still yet to be done. until we get that far, this is a moot point. when we DO get that far... we can add things like: evas_begin(evas); evas_end(evas); that act like a freeze push and pop and when you get back to 0, you wake up the mainloop - via the evas event fd :) we can create a thread local counter for each of these so this increments per thread. we can lock the canvas while itds "begun", or create more imaginative schemes, but to even get that far, we MUST make all the libs threadsafe anyway. > 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). education though is much harder. much much much much much harder. we can push these, but this does NOT preclude threadsafety. > I clearly disagree on that patch going in (and I am still not > discussing the issue of performance here). > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
