Bug using Notifier with asyncio loop

[albireox]

I'm seen a problem when trying to use the new argument loop in a Notifier. I'm using a slcanBus instance and it seems that everytime the file reader gets something it triggers a recv. But in slcanBus that means it reads part of the received message but not the whole thing so it ignores the message or fails (for instance because it reads a character 'T' which should be followed by more characters but those haven't arrived yet).

Using the same code but not specifying a loop seems to work fine.

[albireox]

Looking a bit further, it seems the recv call in notifier.py line 108 doesn't use self.timeout but a timeout=0. Changing to msg = bus.recv(self.timeout) seems to fix the problem.

[christiansandberg]

Hmm, I see. The timeout is supposed to be 0 because it should not be blocking. However, since the serial communication may receive partial messages then we either need to buffer the chunks or use a timeout anyway and hope that the rest of message will arrive in a short time.

[albireox]

I'm testing this with my use case and I still get the same error. If I understand what you did, you now check if what we read has a LINE_TERMINATOR and if not you force another read_until the LINE_TERMINATOR, but after that you process the message regardless of what it received. At least in my case the second read doesn't help because the message hasn't arrived completely. I think what it would need to do is to block or wait until the LINE_TERMINATOR has arrived and not try to process anything before that.

[christiansandberg]

What error do you get? After the read_until (which should return immediately since timeout is 0), I only process the message if a line terminator has been found. Otherwise it returns with None and lets the event loop wait for new data. We don't want to block because we want the event loop to be able to do other stuff while we wait for data.

[albireox]

So, looking into this a bit more carefully. You're right, your change does check twice. I see two different problems. First, my device replies with a series of three \r when it connects. Right now those consecutive \r at the beginning break the code, I think. That can be fixing by adding a

self._buffer = self._buffer.lstrip(self.LINE_TERMINATOR)

at line 119. The second problem is when you get multiple messages at the same time. For instance, the second time _recv_internal gets call in my example with my device it gets

bytearray(b'Z\rT00100300427000001\rZ\rT00100200400020202\r')

The current code tries to parse the first Z, doesn't do anything, and then ignores the rest. I assume the rest will be processed when more messages arrive, but until then they don't get processed.

[albireox]

For reference, if you replace the _on_message_available with this ugly code

    def _on_message_available(self, bus):
        msg = bus.recv(0)
        if msg is not None:
            self._on_message_received(msg)

        while bus._buffer:
            msg = bus.recv(0)
            if msg is not None:
                self._on_message_received(msg)

it seems to works as expected. Of course, the will break other buses without the _buffer attribute.