[Webkit-unassigned] [Bug 22755] New: Next step to Timers in Workers: moving timer code from other places to DOMTimer.

[bugzilla-daemon at webkit.org]

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

           Summary: Next step to Timers in Workers: moving timer code from
                    other places to DOMTimer.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: P2
         Component: HTML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dimich at chromium.org


This prepares for adding means to JSScriptContext to create its own timers
(except threading stuff that is separate):
- Moved more timer code from JSDOMWindowBase to DOMTimer. Removed timerFired()
and simplified install/removeTimeout so when JSWorkerContext will get similar
functionality, there wil be no code duplication.
- Moved TimeoutMap from Document to be a static member on DOMTimer. Also
removed addTimeout/removeTimeout from Document. Same reason as above.
- Removed JSLock lock(false) local variable in ~DOMTimer. It doesn't seem to be
needed there.
- Since Timers now are not recreated across modal operations, the code that
updates interval to be at least 10ms is simpler now.

Next steps:
- teach ScheduledAction how to execute using WorkerContext in addition to
Document.
- make DOMTimer working on a Worker thread
- expose timers off WorkerContext

This makes it easy to add create/remove timeout methods to JSWorkerContext
later since they just create/delete DOMTimer object.


-- 
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.