GRUMBL !!! On Thu, Jul 28, 2011 at 1:13 PM, Mike McCormack <mj.mccorm...@samsung.com> 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.
Before providing a benchmark, please revert your broken code and provide a working solution based on my discussion with gustavo (using Ecore_Pipe). Right know, and before doing benchmark, your solution doesn't work in all case and that's a no go for me. It's already painfull for us when we use thread that I don't want to dig why some user have weird behaviour due to this half working solution. >> 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?" Because it's not Java and most people don't understand thread. From my own experience what ever you try to do, people will mess with thread. Not a single student coming out of school will get thread right and it will take them a lot of time before they can effectivly use it safely and in a more efficient way than just using a callback/state machine as the ecore main loop. That's why we have Ecore_Thread, to put a clear barier where you use thread only for your calc and blocking operation and go back into the main loop for any UI related operation. It's here to help every developper including us. > Adding thread safety means: > > * one whole class of API misuse and potential problems is gone And one whole class of new bug to dig in harder is in. > * people who think they know what they're doing can use threads without > worrying that ecore is a source of problems If they know thread, then ecore wouldn't be the 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." No it's not. Maybe we're E-lite developer, but our thread code is starting to be fine only since a few month (and i wouldn't bet on it). That's why we provide infra with Ecore_Thread to minimize the risk of race condition and other nice dead lock. It's also why we will certainly use Ecore to do the sharing ressource daemon for next generation of pipeline rendering, to avoid going into the async mess again. And I agree, we provide the same infra for 3rd parties as we want to use inside EFL, that's called Ecore_Thread. To be really clear from my point of view, thread should only be used for blocking operation and heavy computational task. Trying to advertise more than that will just end with more bug to fix in user application. Some time, it's better not to provide to much, just to be sure that most people take the wrong path. As a side note, when I want student to hit a wall, I just lure them into using thread, none of them ever get anything working properly with it in any sane amount of time. I personnally thing that Grand Central Dispatch from Apple is the right design when we are speaking about thread (http://en.wikipedia.org/wiki/Grand_Central_Dispatch) and that the Java approach to make everything thread safe is the wrong direction. But if you really want thread safety in Ecore, I will not oppose it as long as you do it technically correct, not the way you did with that patch ! -- 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
