Skip to content

Conversation

@BenGardiner
Copy link
Contributor

Summary of Changes

There are definitely cases of client code that end up passing timeout=None to _recv_internal(). Several other interfaces/*.py are prepared for this e.g. canalystii usb2can canlib_vcinpl2 gs_usb.py

For cantact I think the right thing to do is set default timeout to 0 if None is provided.
There are definitely cases of client code that end up passing timeout=None to _recv_internal(). Several other interfaces/*.py are prepared for this e.g. canalystii usb2can canlib_vcinpl2 gs_usb.py

For cantact I think the right thing to do is set default timeout to 0 if None is provided.

Type of Change

  • Bug fix
  • New feature
  • Documentation update
  • Refactoring
  • Other (please describe):

Checklist

  • I have followed the contribution guide.
  • I have added or updated tests as appropriate.
  • I have added or updated documentation as appropriate.
  • I have added a news fragment for towncrier.
  • All checks and tests pass (tox).

There are definitely cases of client code that end up passing timeout=None to _recv_internal(). Several other interfaces/*.py are prepared for this e.g. canalystii usb2can canlib_vcinpl2 gs_usb.py

For cantact I think the right thing to do is set default timeout to 0 if None is provided.
@zariiii9003
Copy link
Collaborator

But None means it should block indefinitely until a message is received.

The cantact lib calls recv_timeout(std::time::Duration::from_millis(timeout_ms) under the hood. I think it would be better to set timeout to a very large number (2**64 - 1) instead of 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants