Bug 54072

Summary: nrwt multiprocessing: add code to handle interrupts and wedged threads
Product: WebKit Reporter: Dirk Pranke <dpranke>
Component: New BugsAssignee: Dirk Pranke <dpranke>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, mihaip, ojan, tony
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Bug Depends on: 54071    
Bug Blocks: 49566, 54074, 54082    
Attachments:
Description Flags
Patch
none
fix missing variable assignment in _check_if_done()
none
merge in changes from 54070, 54071, update w/ feedback from mihai, tony
none
merge in more changes from 54070, 54071
none
upload w/ more feedback from tony - remove the _Multiprocessing_Process hack completely, just make the class conditionally defined none

Dirk Pranke
Reported 2011-02-08 23:58:26 PST
nrwt multiprocessing: add code to handle interrupts and wedged threads
Attachments
Patch (14.56 KB, patch)
2011-02-09 00:06 PST, Dirk Pranke
no flags
fix missing variable assignment in _check_if_done() (14.59 KB, patch)
2011-02-09 00:24 PST, Dirk Pranke
no flags
merge in changes from 54070, 54071, update w/ feedback from mihai, tony (19.20 KB, patch)
2011-02-11 15:39 PST, Dirk Pranke
no flags
merge in more changes from 54070, 54071 (20.96 KB, patch)
2011-02-11 18:04 PST, Dirk Pranke
no flags
upload w/ more feedback from tony - remove the _Multiprocessing_Process hack completely, just make the class conditionally defined (22.24 KB, patch)
2011-02-14 14:09 PST, Dirk Pranke
no flags
Dirk Pranke
Comment 1 2011-02-09 00:06:28 PST
Dirk Pranke
Comment 2 2011-02-09 00:24:30 PST
Created attachment 81763 [details] fix missing variable assignment in _check_if_done()
Mihai Parparita
Comment 3 2011-02-11 11:58:01 PST
Comment on attachment 81763 [details] fix missing variable assignment in _check_if_done() View in context: https://bugs.webkit.org/attachment.cgi?id=81763&action=review > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:267 > + return self._alive Maybe I'm missing something, but I'm not seeing _alive being set in either this patch, the patch for bug 54071 (which this depends on), or the currently checked in code.
Dirk Pranke
Comment 4 2011-02-11 12:45:08 PST
(In reply to comment #3) > (From update of attachment 81763 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=81763&action=review > > > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:267 > > + return self._alive > > Maybe I'm missing something, but I'm not seeing _alive being set in either this patch, the patch for bug 54071 (which this depends on), or the currently checked in code. Alive shows up in the patch on bug 54070 (which 54071 depends on). Sorry, a pipeline of patches can be confusing ... -- Dirk
Dirk Pranke
Comment 5 2011-02-11 15:39:28 PST
Created attachment 82199 [details] merge in changes from 54070, 54071, update w/ feedback from mihai, tony
Dirk Pranke
Comment 6 2011-02-11 18:04:49 PST
Created attachment 82218 [details] merge in more changes from 54070, 54071
Tony Chang
Comment 7 2011-02-14 10:38:18 PST
Comment on attachment 82218 [details] merge in more changes from 54070, 54071 View in context: https://bugs.webkit.org/attachment.cgi?id=82218&action=review > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:279 > + def is_alive(self): > + # FIXME: We can remove this once everyone is on 2.6. > + return self.isAlive() is_alive = isAlive (probably with the comment). > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:328 > + _Multiprocessing_Process.is_alive(self) multiprocessing.Process.is_alive My earlier thought was if _Process/_MultiProcessWorkerConnection is the same as _Thread/_ThreadedWorkerConnection on python 2.5, maybe we shouldn't even declare this object in python 2.5 (i.e., put the whole class definition behind an if multiprocessing). That would avoid some of these branches in the object itself. > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker_unittest.py:192 > + oc.restore_output() Should this be part of the try/finally? > Tools/Scripts/webkitpy/layout_tests/layout_package/worker.py:87 > + # FIXME: Figure out how to send a message with a traceback. I see, the traceback can't be pickled? Maybe we should just send back the stringified traceback?
Dirk Pranke
Comment 8 2011-02-14 14:00:38 PST
(In reply to comment #7) > (From update of attachment 82218 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=82218&action=review > > > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:279 > > + def is_alive(self): > > + # FIXME: We can remove this once everyone is on 2.6. > > + return self.isAlive() > > is_alive = isAlive (probably with the comment). > > > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker.py:328 > > + _Multiprocessing_Process.is_alive(self) > > multiprocessing.Process.is_alive > > My earlier thought was if _Process/_MultiProcessWorkerConnection is the same as _Thread/_ThreadedWorkerConnection on python 2.5, maybe we shouldn't even declare this object in python 2.5 (i.e., put the whole class definition behind an if multiprocessing). That would avoid some of these branches in the object itself. > I guess for some reason I was thinking that declaring a top-level name conditionally was a bad idea, but now I can't see any real downside, and it does make the code somewhat cleaner. Will do. > > Tools/Scripts/webkitpy/layout_tests/layout_package/manager_worker_broker_unittest.py:192 > > + oc.restore_output() > > Should this be part of the try/finally? > Done. > > Tools/Scripts/webkitpy/layout_tests/layout_package/worker.py:87 > > + # FIXME: Figure out how to send a message with a traceback. > > I see, the traceback can't be pickled? Maybe we should just send back the stringified traceback? Correct. Directly calling str() on the traceback is useless (it just prints out the object handle), and so the FIXME is to do something like log the error to a dummy handler and then send the array of strings, if that does turn out to be useful. I'm not convinced it's worth the effort over just logging the traceback here and sending the exception w/o the traceback. Hence the fixme ... to poke into it some more at some later date when I have time.
Dirk Pranke
Comment 9 2011-02-14 14:09:37 PST
Created attachment 82359 [details] upload w/ more feedback from tony - remove the _Multiprocessing_Process hack completely, just make the class conditionally defined
Dirk Pranke
Comment 10 2011-02-14 14:13:24 PST
Note You need to log in before you can comment on or make changes to this bug.