PCAN Receive does not implement timeouts

[hardbyte]

Originally reported by: Sam Kreuze (Bitbucket: Kreuzade, GitHub: Kreuzade)

---

I've been trying for a while now to receive messages using this library with a PCAN device. I noticed today that the "recv" function does not use the "timeout" variable in the function in pcan.py. Is there a reason for this? or am I missing something?

---

• Bitbucket: https://bitbucket.org/hardbyte/python-can/issue/42

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

While a coworker also commented on this awhile back, I am back on a different aspect. Since there is no timeout for recv(), that makes rx_thread() suck down an entire CPU when using a Notifier since it never yields. Hopefully I'll be taking a look at this in the morning. If not, then in the next week. Or just putting in my else: sleep(0.001) if using a PCAN device... :]

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

I didn't feel like getting into the PCAN_RECEIVE_EVENT so I just went lazy with the sleep buried down in pcan.py. Anyways, here's a patch. Let me know what you think, I can figure out how to setup a branch and a pull request if needed.

I suppose I should note that it's bedtime and this has very limited testing. I'll share when I have any changes or better confidence.

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

Switched from monotonic() to perf_counter() and committed in my fork.

[hardbyte]

Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):

---

Great, looks good to me. Once you're happy with the testing please make a PR.

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

@Kreuzade, do you want to give it a try? I have been using it but haven't explicitly tried to break it or written any direct tests for it. I do continue to have performance issues with my application that I have not diagnosed, but it is quite a bit better with this.

[hardbyte]

Original comment by Sam Kreuze (Bitbucket: Kreuzade, GitHub: Kreuzade):

---

Thank you, @altendky. Unfortunately a coworker is borrowing my PCAN adapter so I'll have to give this a try when I get it back. Thanks again for your efforts!

[hardbyte]

Original comment by Sam Kreuze (Bitbucket: Kreuzade, GitHub: Kreuzade):

---

@altendky, I was able to try this out just now. I forget why but I'm using python27 so I replaced time.perf_counter() with time.clock() and everything seems to work.

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

Thanks for noticing that. I believe that time.perf_counter() was introduced somewhere in 3. I'll look into handling that difference.

[hardbyte]

Original comment by Kyle Altendorf (Bitbucket: altendky, GitHub: altendky):

---

Submitted pull request #16 with selection of time.perf_counter() vs. time.clock() based on Python version.

[hardbyte]

Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):

---

Respect deprecation of time.clock, introduction of time.perf_counter

See issue #42

[hardbyte]

Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):

---

Add timeout support to PcanBus.recv()

See issue #42

[hardbyte]

Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):

---

I've merged this in, I'll create a new issue for implementing a non-polling version using PCAN_RECEIVE_EVENT