On Tue, Aug 7, 2012 at 11:28 AM, Cedric BAIL <[email protected]> wrote: > On Tue, Aug 7, 2012 at 10:18 AM, Brian Wang <[email protected]> wrote: >> In ecore_thread.c:_ecore_thread_shutdown(), >> if there is still some _ecore_running_job, >> ecore_thread_cancel() will be called while >> _ecore_pending_job_threads_mutex is being held. >> In ecore_thread_cancel(), >> it will try to acquire the same mutex, causing >> _ecore_thread_shutdown() to freeze. >> >> That's how I read the code while I was trying to debug why my app does >> not shutdown completely (there >> is a thread running, without being cancelled before calling elm_exit()). >> >> I do not know how to fix it other than moving LKU before calling >> ecore_thread_cancel; however, I do not know >> if it's safe to do or not. > > Sadly, it is not as we need to take lock as long as we walk on that > list. I will look at it and find a proper solution, but basically > ecore_thread_cancel doesn't access the same list. So either I use > another lock when accessing the _ecore_running_job or I tell somehow > ecore_thread_cancel to not even try to access the > _ecore_pending_job_threads and _ecore_pending_job_threads_feedback. > Need to think, quickly, about it. I need to fix that before EFL > release.
Ok, fixed in r74953 by using another mutex. -- Cedric BAIL ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
