[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