Bug 131078
| Summary: | some Web worker threads never terminate | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | abaldeva |
| Component: | WebCore Misc. | Assignee: | Mark Lam <mark.lam> |
| Status: | ASSIGNED | ||
| Severity: | Major | CC: | mark.lam |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
abaldeva
Hi,
If a web worker is executing a javascript in a while(true){..} loop, the OS Worker thread created for it never terminates. An example can be seen here - http://www.whatwg.org/demos/workers/primes/page.html
The watchdog mechanism starts out as disabled. This means that timeout JIT::emit_op_loop_hint in JITOpcodes.cpp never emits the timeout check mechanism. Thus, when the web worker is expected to terminate (either by explicitly calling worker.terminate() or moving away from the page), execution never comes out of script->evaluate in WorkerThread::workerThread(). This results in the OS thread hanging around.
The C Loop interpreter backend has the same issue except that it ends up waiting on m_timerDidFire in watchdog which never turns true.
--Arpit
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
abaldeva
One possible solution to this problem might be to start VM watchdog timer with a small timeout value (1-2 sec? )and a callback (using Watchdog::setTimeLimit API). This will force the script execution to check the WorkerScriptController regularly. The callback keeps returning false unless the WorkerScriptController::scheduleExecutionTermination has been called.
--Arpit
Mark Lam
I’ve confirmed that m_didFire is indeed not reset. Let me think about what the right thing to do is, and implement a fix.
Mark Lam
(In reply to comment #2)
> I’ve confirmed that m_didFire is indeed not reset. Let me think about what
> the right thing to do is, and implement a fix.
Oops. Commented in wrong bug. Please disregard.