On Thu, 28 Jul 2011, Mike McCormack wrote:
> On 07/28/2011 07:32 PM, Cedric BAIL wrote: > >> Maybe stable, but the rendered scene will not make sense and be highly >> difficult to debug. So spank and point people to the right solution. > > This is ecore, not evas. Adding timers from a thread makes sense to me. > > I'm not proposing this as a solution for Evas. Perhaps adding a thread > check is better there... I haven't looked at it closely. > >>> * nobody complained when I added checks to show that ecore calls are coming >>> from the same thread, even though the performance "impact" would be >>> comparable. >>> (See ECORE_MAIN_LOOP_ASSERT) >> >> Because if needed, we can turn it off without breaking application or >> any behaviour. Something that was working with it on will work with it >> off. It something that we could use in a development build and remove >> from the production build without the need to worry about it at all. > > If you're worried about this, how about I add a function call that > can set the _ecore_lock() and _ecore_unlock() functions. If they are > NULL, the won't be called. > > Also, if you worry so much about performance, please let me know what > benchmarking you want done to show the overhead. > >> I thing that this will get confusing and people will introduce more >> bug, because the barrier with thread safety will be blured, some >> function call will work, some won't. At the end, I think you are >> increasing the complexity of the EFL without any benefit, you will >> have more and more complex code to debug (because every thing will not >> be thread safe). I really am more for a macro that display a spank >> with backtrace and do nothing in all efl function call (including >> evas, edje and elementary), that point to Ecore_Thread documentation. >> In fact halt of that code is already provided by eina, I can provide >> it quickly if that feat your need. This will put the burden of the fix >> on the developer and not you. They will know exactly where and how to >> fix it. > > I have already added code to print warnings. It helps, but the response is > usually, "but why isn't EFL thread safe?" tell them to read the preamble there : http://docs.enlightenment.org/auto/ecore/Ecore_Main_Loop_Page.html Vincent > > Adding thread safety means: > > * one whole class of API misuse and potential problems is gone > * people who think they know what they're doing can use threads without > worrying that ecore is a source of problems > * we offer the same features to 3rd parties as we want to use inside EFL. > > It's a bit hypocritical to say "Well, the EVAS code can use threads, > because we're E-lite developers, but users of our API should never be able > to use threads, and should get spanked for doing so." > > thanks, > > Mike > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
