[Webkit-unassigned] [Bug 57090] [V8] Possible data race problem in v8/WorkerScriptController (reported by tsan)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 29 20:36:58 PDT 2011


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


Dmitry Titov <dimich at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #86904|0                           |1
        is obsolete|                            |




--- Comment #5 from Dmitry Titov <dimich at chromium.org>  2011-03-29 20:36:58 PST ---
Created an attachment (id=87455)
 --> (https://bugs.webkit.org/attachment.cgi?id=87455&action=review)
Patch

Work in progress. It applies to both JSC and V8, so I'm removing "[v8]" in the title of the bug

The mutex is gone! It should not be there, since guarding the entry into JS engine is only possible from the same thread, otherwise the whole "entry into JS" would have to be under a lock.

The patch makes the bit preventing the reentry to be only set/checked on a single thread and so the mutex is no longer needed. The logic of termination:

1. If Worker is merely "Closed", as in WorkerGlobalScope.Close() - the WorkerContext::m_isClosing is set and that eventually drains Task queue and terminates the worker
2. If Worker.terminate() is called or parent page closes - the WorkerScriptController::scheduleExecutionTermination() is called. This will eventually (so no locking needed) propagate to the worker thread and raise termination exception. Upon exit from JSC or V8 with that exception, we use WorkerScriptController::forbidExecution() to set up a flag.
3. After the flag is set, we avoid reentering JS in EventListener and WorkerScriptController code.

The only difference between JSC and V8 is that JSC's Terminator is not guaranteed to immediately raise termination exception, so additional check is added for the Terminator::shouldTerminate() in addition to exception check.

Tests run fine. I will run V8 tests and update patch with ChanegLogs etc.

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



More information about the webkit-unassigned mailing list