[Webkit-unassigned] [Bug 137485] [GLIB] Split GMainLoopSource moving thread safe implementation to its own class GThreadSafeMainLoopSource

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137485





--- Comment #15 from Carlos Garcia Campos <cgarcia at igalia.com>  2014-10-10 05:16:59 PST ---
(In reply to comment #14)
> (From update of attachment 239411 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=239411&action=review
> 
> >>>> Source/WTF/wtf/gobject/GMutexLocker.h:78
> >>>> +            return;
> >>> 
> >>> Hmm this makes the template useless, because the recursive mutexes will act as normal ones, won't they?
> >> 
> >> Hmm this makes the template useless, because the recursive mutexes will act as normal ones, won't they?
> > 
> > The idea is that the same GMutexLocker object shouldn't lock a mutex already locked, but two different GMutexLocker objects, wrapping the same GRecMutex should be allowed. Which is the case I'm covering here, schedule calls cancel, both locking the mutex, but using different GMutexLocker objects.
> 
> Right. Too many mutexes and lockers :). Couldn't we achieve the same by using the _try_ variants in MutexWrapper object?

No, try_lock is in case it's locked by *another* thread, to not block. But if locked by the same thread, in case of non-recursive mutex, the behaviour is undefined.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.