On Sun, Nov 14, 2010 at 10:00 AM, Enlightenment SVN <no-re...@enlightenment.org> wrote: > Log: > see comment. > > > Author: raster > Date: 2010-11-14 01:00:24 -0800 (Sun, 14 Nov 2010) > New Revision: 54549 > > Modified: > trunk/ecore/src/lib/ecore/ecore_thread.c > > Modified: trunk/ecore/src/lib/ecore/ecore_thread.c > =================================================================== > --- trunk/ecore/src/lib/ecore/ecore_thread.c 2010-11-14 07:32:03 UTC (rev > 54548) > +++ trunk/ecore/src/lib/ecore/ecore_thread.c 2010-11-14 09:00:24 UTC (rev > 54549) > @@ -336,7 +336,10 @@ > pthread_mutex_unlock(&_ecore_pending_job_threads_mutex); > > /* Sleep a little to prevent premature death */ > - usleep(200); > +// any code with something like this in it to "avoid some race condition" > +// especially with just 200micro-seconds is asking for trouble. disable > +// this. > +// usleep(200); > > pthread_mutex_lock(&_ecore_pending_job_threads_mutex); > if (_ecore_pending_job_threads) >
Nah, it shouldn't trigger any race condition, it's here to delay a little bit the death of the thread. Most of the time, you first cancel all pending Ecore_Thread before adding some back. By sleeping a small amount of time before death, this give a chance to reuse the thread instead of recreating them. If there is a race condition, it could be below if I don't properly lock the thread counter and think there is a running thread when the last chance to not die is gone. -- Cedric BAIL ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
