diff options
| author | Olivier Dony <odo@odoo.com> | 2018-10-26 17:38:55 +0000 |
|---|---|---|
| committer | Olivier Dony <odo@odoo.com> | 2018-11-02 11:04:35 +0000 |
| commit | 717b7249d5d47421894052e8ad8dc67bc6f3603f (patch) | |
| tree | 3c856f10e9d34956358d8965e324ac08b379c941 /addons/web/static/src/js/fields/relational_fields.js | |
| parent | f20cd3db7565b04a96066aa41e08cd3679eb86c8 (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/fields/relational_fields.js')
0 files changed, 0 insertions, 0 deletions
