summaryrefslogtreecommitdiff
path: root/addons/web/static/src/js/views/basic/basic_model.js
diff options
context:
space:
mode:
authorOlivier Dony <odo@odoo.com>2018-10-26 17:38:55 +0000
committerOlivier Dony <odo@odoo.com>2018-11-02 11:04:35 +0000
commit717b7249d5d47421894052e8ad8dc67bc6f3603f (patch)
tree3c856f10e9d34956358d8965e324ac08b379c941 /addons/web/static/src/js/views/basic/basic_model.js
parentf20cd3db7565b04a96066aa41e08cd3679eb86c8 (diff)
[FIX] server: always consume wakeup bytes from signals
Due to the implementation of PEP-475[1] in Python 3.5, revision e98e8e9b1bdf8c3a3bcf74b7648b0829c21d356a used the recommended technique of wakeup file descriptors in order to detect interruption of sleep() and select() by signals, when running in multi-process mode (workers > 0). The technique works well, however the initial patch never bothered to read the byte that is written to the wakeup pipe when a signal is processed. This does not matter when the signal is meant to shut down the server, but it matters when the signal is SIGQUIT: it simply prints thread dumps, and continues operating normally. As a consequence, that byte remains in the wakeup pipe forever, causing all the subsequent select/sleep calls to return immediately because the wakeup fd *is* already ready. The symptom was that worker processes would start cycling their main run loop very fast after receiving a SIGQUIT signal, eating 100% CPU. This patch ensures we always empty the wakeup pipe after an interruptible call, to avoid this effect. It also refactors another occurrence of the "empty pipe" pattern, in the PreforkServer, and incidentally uses readable aliases for the file descriptors bound to the ends of the wakeup pipe (wakeup_fd_r / wakeup_fd_w). [1] https://www.python.org/dev/peps/pep-0475 closes odoo/odoo#28356
Diffstat (limited to 'addons/web/static/src/js/views/basic/basic_model.js')
0 files changed, 0 insertions, 0 deletions