From: Michael Lass <bevan@bi-co.net>
Date: Fri, 30 Oct 2020 22:57:10 +0000 (+0100)
Subject: Do not prematurely stop waiting for an answer from the message queue
X-Git-Tag: 5.7.0~2^2
X-Git-Url: https://git.ayoreis.com/Adafruit_Blinka-hackapet.git/commitdiff_plain/4305b552ea1be7f6a5ef3e8ae2f027bab443012b?ds=inline;hp=4305b552ea1be7f6a5ef3e8ae2f027bab443012b

Do not prematurely stop waiting for an answer from the message queue

When requesting data from libgpiod_pulsein via the message queue, we
always expect an answer. Prematurely stopping to wait for an answer can
only do harm. If we do not read the expected answer from the mq, it will
stay there and be read (falsely) as an answer to the following request.

Example:

* We request a pulse length by sending '^'.
* Due to high system load, libgpiod_pulsein does not send a response in
  time.
* We timeout with a RuntimeError. This is verly likely ignored by the
  calling code since RuntimeErrors are thrown with every invalid
  reading such that the calling code _has to_ ignore these errors.
* We trigger a new sensor reading (pause-clean-resume).
* We request the length of the pulse buffer by sending 'l'.
* We read from the message queue. The response we get now is the
  response to our original '^' request. Let this response be 100.
* We now assume 100 elements in the pulse buffer. This is of course
  wrong and will lead to all sorts of errors.

The only reason to timeout on an expected answer is probably during
initialization when we are not sure if the communication via message
queue has been successfully set up. In all other cases we should just
block and never timeout.
---