gecko-dev/python/mozlint
Andrew Halberstadt 35ace05949 Bug 1369711 - [mozlint] Make sure KeyboardInterrupts are handled well wherever they happen r=gps
There a few pieces needed here to properly handle KeyboardInterrupts.

1. All in-progress work needs to abort. Ideally the underlying linters will be
able to catch KeyboardInterrupt, and return partial results (like the flake8
linter does). Linters may alternatively allow the KeyboardInterrupt to
propagate up. Mozlint will catch and handle this appropriately, though any
results found will be lost. The only change to this behaviour was fixing a bug
in the flake8 linter.

2. Any unstarted jobs need to be canceled. In concurrent.futures, there are two
different queues. First, jobs are placed on the work queue, which is just a list
maintained by the parent process. As workers become available, jobs are moved
off the work queue, and onto the call queue (which is a multiprocessing.Queue).
Jobs that live on the work queue can be canceled with 'future.cancel()', whereas
jobs that live on the call queue cannot. The number of extra jobs that are stored
on the call queue is determined by this variable:
https://hg.mozilla.org/mozilla-central/file/deb7714a7bcd/third_party/python/futures/concurrent/futures/process.py#l86

In this patch, the parent process' sigint handler (which will be called on Ctrl-C)
is responsible for canceling all the jobs on the work queue. For the jobs on the
call queue, the best we can do is set a global variable that tells workers to
abort early.

3. Idle workers should exit gracefully. When there are no more jobs left, workers
will block on the call queue (either waiting for more jobs, or waiting for the
executor to send the shutdown signal). If a KeyboardInterrupt is received while a
worker is blocking, it isn't possible to intercept that anywhere (due to quirks
of how concurrent.futures is implemented). The InterruptableQueue class was
created to solve this problem. It will return None instead of propagating
KeyboardInterrupt. A None value will wake the worker up and tell it to gracefully
shutdown. This way, we avoid cryptic tracebacks in the output.

With all of these various pieces solved, pressing Ctrl-C appears to always exit
gracefully, sometimes even printing partial results.

MozReview-Commit-ID: 36Pe3bbUKmk

--HG--
extra : rebase_source : d4c312ee5cc3679eeee1407c5521aed679f84ad4
extra : source : a93a00141bf62f6bc9e30934c0e56f6b2e434bf0
2018-02-23 08:55:06 -05:00
..
mozlint Bug 1369711 - [mozlint] Make sure KeyboardInterrupts are handled well wherever they happen r=gps 2018-02-23 08:55:06 -05:00
test Bug 1369711 - [mozlint] Make sure KeyboardInterrupts are handled well wherever they happen r=gps 2018-02-23 08:55:06 -05:00
setup.py Bug 1397423 - Enable py2 linter on python/mozlint. r=ahal 2017-09-06 22:52:46 -04:00