[Webkit-unassigned] [Bug 26565] Windows version of Mutex.lock() should ASSERT on re-entrance

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 22 12:01:16 PDT 2009


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


jorlow at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com




------- Comment #1 from jorlow at chromium.org  2009-06-22 12:01 PDT -------
I looked at the code, and it seems the only change necessary is adding the
following ASSERT in JavaScriptCore/wtf/threadingwin.cpp's Mutex::lock()
function:

void Mutex::lock()
{
    EnterCriticalSection(&m_mutex.m_internalMutex);
    ++m_mutex.m_recursionCount;
    ASSERT(m_mutex.m_recursionCount == 1);
}

Mutex::tryLock already has the correct behavior.

Unfortunately, it seems that safari.exe relies on the recursive behavior. 
Obviously I have no way to fix these dependencies, so it seems that this is a
non-starter (at least for someone outside of Apple).  I still think it's a good
idea though.

If Safari's Windows code cannot possibly avoid its re-entrance assumption,
maybe we could create a sub-class of Mutex called ReentrantMutex.  Only the
constructor and lock would need to be overridden.  (No need for anything to be
virtual...which would obviously not be practical anyway.)


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



More information about the webkit-unassigned mailing list