Bug 23560 - Implement SharedTimer on WorkerRunLoop
Summary: Implement SharedTimer on WorkerRunLoop
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 23488
Blocks: 22718
  Show dependency treegraph
 
Reported: 2009-01-26 17:09 PST by Dmitry Titov
Modified: 2009-02-03 01:19 PST (History)
2 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Titov 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 Dmitry Titov 2009-01-26 17:48:37 PST
Created attachment 27060 [details]
Proposed patch
Comment 2 Alexey Proskuryakov 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 Darin Adler 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 Dmitry Titov 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 Dmitry Titov 2009-01-27 13:44:50 PST
Created attachment 27085 [details]
Updated patch

Removed SharedTimer implementation into a private class. WorkerRunLoop has an instance of it.
Comment 6 Mark Rowe (bdash) 2009-01-27 23:31:49 PST
Comment on attachment 27085 [details]
Updated patch

> -        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 Dmitry Titov 2009-01-28 17:58:30 PST
Created attachment 27135 [details]
Updated patch

Thanks Mark!
Updated the patch.
Comment 8 Dmitry Titov 2009-02-02 08:21:51 PST
bug 23488 was resolved, this bug is not blocked anymore. Same patch.
Comment 9 Alexey Proskuryakov 2009-02-03 00:57:16 PST
Comment on attachment 27135 [details]
Updated patch

> +    {}

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 Alexey Proskuryakov 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 Alexey Proskuryakov 2009-02-03 01:19:08 PST
And committed JavaScriptCore parts in revision 40533.