This is still racy, just a tiny bit less... If at this point, a lock is still legal, nothing prevents it from taking the lock (or referencing the block) just a second afterwards, no? So it still may be broken. Can't we free a locked lock? I'd imagine that to be possible (though again, it doesn't solve the issue at hand).
On 05/08/16 15:51, Carsten Haitzler wrote: > raster pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=26db5d5056a948dc41da65b88a87e575ed21c1eb > > commit 26db5d5056a948dc41da65b88a87e575ed21c1eb > Author: Carsten Haitzler (Rasterman) <[email protected]> > Date: Fri Aug 5 23:51:03 2016 +0900 > > eina thread queue - ensure blocks cannot be freed until lock+unlock > > just in case... check blocks cannot be freed until locked and unlocked > just in case someone still is holding a lock. > --- > src/lib/eina/eina_thread_queue.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/src/lib/eina/eina_thread_queue.c > b/src/lib/eina/eina_thread_queue.c > index 190d772..d5bee95 100644 > --- a/src/lib/eina/eina_thread_queue.c > +++ b/src/lib/eina/eina_thread_queue.c > @@ -137,8 +137,12 @@ _eina_thread_queue_msg_block_new(int size) > static void > _eina_thread_queue_msg_block_real_free(Eina_Thread_Queue_Msg_Block *blk) > { > + eina_lock_take(&(blk->lock_non_0_ref)); > + eina_lock_release(&(blk->lock_non_0_ref)); > eina_lock_free(&(blk->lock_non_0_ref)); > #ifndef ATOMIC > + eina_lock_take(&(blk->lock_ref)); > + eina_lock_release(&(blk->lock_ref)); > eina_spinlock_free(&(blk->lock_ref)); > #endif > free(blk); > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
