Bug 23560 - Implement SharedTimer on WorkerRunLoop
: Implement SharedTimer on WorkerRunLoop
Status: RESOLVED FIXED
: WebKit
WebCore Misc.
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
: 23488
: 22718
  Show dependency treegraph
 
Reported: 2009-01-26 17:09 PST by
Modified: 2009-02-03 01:19 PST (History)


Attachments
Proposed patch (5.06 KB, patch)
2009-01-26 17:48 PST, Dmitry Titov
no flags Review Patch | Details | Formatted Diff | Diff
Updated patch (5.62 KB, patch)
2009-01-27 13:44 PST, Dmitry Titov
no flags Review Patch | Details | Formatted Diff | Diff
Updated patch (5.69 KB, patch)
2009-01-28 17:58 PST, Dmitry Titov
ap: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-01-26 17:09:50 PST
This patch depends on 23488 which is not yet landed.

It implements SharedTimer interface on WorkerRunLoop and initializes thread-specific copy of ThreadTimers for worker thread.

Patch is coming.
------- Comment #1 From 2009-01-26 17:48:37 PST -------
Created an attachment (id=27060) [details]
Proposed patch
------- Comment #2 From 2009-01-27 12:04:32 PST -------
+    class WorkerRunLoop : public SharedTimer {

Is it really right to say that a run loop is an instance of SharedTimer? This results in awkward calls like runLoop.stop() that are difficult to interpret as being timer-related.
------- Comment #3 From 2009-01-27 12:19:49 PST -------
(In reply to comment #2)
> +    class WorkerRunLoop : public SharedTimer {
> 
> Is it really right to say that a run loop is an instance of SharedTimer? This
> results in awkward calls like runLoop.stop() that are difficult to interpret as
> being timer-related.

In case it's not obvious, other options are to use private inheritance, or to have a shared timer as a data member.
------- Comment #4 From 2009-01-27 12:25:55 PST -------
Thanks guys. I think having something like a ThreadSharedTimer as a member of WorkerRunLoop will remove those methods from the run loop itself. Updated patch is coming...
------- Comment #5 From 2009-01-27 13:44:50 PST -------
Created an attachment (id=27085) [details]
Updated patch

Removed SharedTimer implementation into a private class. WorkerRunLoop has an instance of it.
------- Comment #6 From 2009-01-27 23:31:49 PST -------
(From update of attachment 27085 [details])
> -        task->performTask(context);
> +        if (result == MessageQueueTerminated)
> +            break;
> +        else if (result == MessageQueueMessageReceived)
> +            task->performTask(context);
> +        else
> +            m_sharedTimer->fire();

You don't need an "else" after the "break".
------- Comment #7 From 2009-01-28 17:58:30 PST -------
Created an attachment (id=27135) [details]
Updated patch

Thanks Mark!
Updated the patch.
------- Comment #8 From 2009-02-02 08:21:51 PST -------
bug 23488 was resolved, this bug is not blocked anymore. Same patch.
------- Comment #9 From 2009-02-03 00:57:16 PST -------
(From update of attachment 27135 [details])
> +    {}

We usually put braces on separate lines in this context.

> +    bool isActive() { return m_sharedTimerFunction && m_nextFireTime != 0; }

No need for "!= 0" here.

r=me
------- Comment #10 From 2009-02-03 01:14:19 PST -------
Committed revision 40532.

+        * dom/WorkerRunLoop.h:
+        Add member of type OwnPtr<WorkerSharedTimer>

A great comment says why a change was made, not what the change was. But I know that it's difficult to find something to say about trivial changes.
------- Comment #11 From 2009-02-03 01:19:08 PST -------
And committed JavaScriptCore parts in revision 40533.