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?" 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
