WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
50374
nrwt multiprocessing - simpify message_broker and move logic back into run_webkit_tests
https://bugs.webkit.org/show_bug.cgi?id=50374
Summary
nrwt multiprocessing - simpify message_broker and move logic back into run_we...
Dirk Pranke
Reported
2010-12-01 22:53:10 PST
nrwt multiprocessing - move logic back into run_webkit_tests
Attachments
Patch
(22.91 KB, patch)
2010-12-01 23:48 PST
,
Dirk Pranke
no flags
Details
Formatted Diff
Diff
update w/ review feedback
(24.49 KB, patch)
2010-12-02 17:38 PST
,
Dirk Pranke
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Dirk Pranke
Comment 1
2010-12-01 23:48:22 PST
Created
attachment 75357
[details]
Patch
Tony Chang
Comment 2
2010-12-02 12:15:46 PST
Comment on
attachment 75357
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=75357&action=review
Seems like this is mostly just moving stuff around.
> WebKitTools/Scripts/webkitpy/layout_tests/layout_package/message_broker.py:117 > + thread = super(_MultiThreadedBroker, self).start_worker(test_runner,
Nit: I think the preferred calling convention is _WorkerMessageBroker.start_worker(self, test_runner, worker_number) because super can be ambiguous in the case of multiple inheritance. I think this is consistent to how we use the super class name in __init__.
> WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:233 > +# FIXME: This name is somewhat misleading because the actual workers have > +# their own internal state in TestShellThread. However, a better name for > +# this has yet to be found.
Nit: I think this name is fine for now and the docstring describes it. I would just remove this comment.
> WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:269 > + # or processes. This is a bit awkward but a better name has yet to
Nit: Missing closing paren.
> WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:687 > + for thread in [w.thread for w in workers.values()]: > + thread_timings.append({'name': thread.name(),
This is a bit convoluted. Why not just: for worker in workers.values(): thread = worker.thread thread_timings.append(....
Dirk Pranke
Comment 3
2010-12-02 14:03:17 PST
(In reply to
comment #2
)
> (From update of
attachment 75357
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=75357&action=review
> > Seems like this is mostly just moving stuff around. >
Yeah, pretty much.
> > WebKitTools/Scripts/webkitpy/layout_tests/layout_package/message_broker.py:117 > > + thread = super(_MultiThreadedBroker, self).start_worker(test_runner, > > Nit: I think the preferred calling convention is _WorkerMessageBroker.start_worker(self, test_runner, worker_number) because super can be ambiguous in the case of multiple inheritance. I think this is consistent to how we use the super class name in __init__. >
Maybe I'm misunderstanding something. Are you're saying it's ambiguous because super() might end up calling threading.start_broker() if MultiThreadedBroker didn't implement the method, and it's better to be explicit about which class you intended to invoke? Yeah, I could agree that that might be clearer, but I wanted to confirm what you were saying before changing anything.
Tony Chang
Comment 4
2010-12-02 14:41:47 PST
(In reply to
comment #3
)
> Maybe I'm misunderstanding something. Are you're saying it's ambiguous because super() might end up calling threading.start_broker() if MultiThreadedBroker didn't implement the method, and it's better to be explicit about which class you intended to invoke?
I'm just saying being explicit is better than using super(). I agree that it's not actually dangerous in this case.
Dirk Pranke
Comment 5
2010-12-02 17:35:29 PST
(In reply to
comment #2
)
> (From update of
attachment 75357
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=75357&action=review
> > Seems like this is mostly just moving stuff around. > > > WebKitTools/Scripts/webkitpy/layout_tests/layout_package/message_broker.py:117 > > + thread = super(_MultiThreadedBroker, self).start_worker(test_runner, > > Nit: I think the preferred calling convention is _WorkerMessageBroker.start_worker(self, test_runner, worker_number) because super can be ambiguous in the case of multiple inheritance. I think this is consistent to how we use the super class name in __init__.
Fixed in
bug 50372
.
> > > WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:233 > > +# FIXME: This name is somewhat misleading because the actual workers have > > +# their own internal state in TestShellThread. However, a better name for > > +# this has yet to be found. > > Nit: I think this name is fine for now and the docstring describes it. I would just remove this comment.
> Done.
> > WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:269 > > + # or processes. This is a bit awkward but a better name has yet to > > Nit: Missing closing paren.
> Fixed.
> > WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py:687 > > + for thread in [w.thread for w in workers.values()]: > > + thread_timings.append({'name': thread.name(), > > This is a bit convoluted. Why not just: > for worker in workers.values(): > thread = worker.thread > thread_timings.append(....
Done. Thanks for the review!
Dirk Pranke
Comment 6
2010-12-02 17:38:09 PST
Created
attachment 75445
[details]
update w/ review feedback
Dirk Pranke
Comment 7
2010-12-02 19:42:04 PST
Committed
r73231
: <
http://trac.webkit.org/changeset/73231
>
Yuta Kitamura
Comment 8
2010-12-03 02:10:00 PST
Hi, It seemed that
r73211
broke Chromium's "Webkit Win (dbg)(2)" bot. Unfortunately, there is some conflict with this change, so I needed to roll out this patch.
http://trac.webkit.org/changeset/73255
Feel free to re-land this patch after
r73211
is rolled out. Thank you for your understandings.
Dirk Pranke
Comment 9
2011-01-11 19:01:10 PST
closing ... the new patches are different.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug