Skip to content

Feature: Synchronized bus instance #315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Jun 13, 2018
Merged

Conversation

felixdivo
Copy link
Collaborator

Adds a can.ThreadSafeBus that can be used as a thread safe drop-in replacement for can.Bus. The send and receive methods are synchronized separately.

@felixdivo
Copy link
Collaborator Author

felixdivo commented May 28, 2018

TODO: Documentation. Done.

Copy link
Collaborator

@christiansandberg christiansandberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thread safe sending makes sense. Not sure about the use case for recv though but might as well do both.

As I've mentioned before, try to separate unrelated changes in different pull requests.

doc/bus.rst Outdated
@@ -37,10 +39,24 @@ Receiving
'''''''''

Reading from the bus is achieved by either calling the :meth:`~can.BusABC.recv` method or
by directly iterating over the bus::
by directly iterating over the bus:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a mistake, see here.

doc/bus.rst Outdated

It can be used exactly like the normal :class:`~can.Bus` class:

my_bus = can.Bus(interface='socketcan', channel='vcan0')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be can.ThreadSafeBus?

setup.py Outdated
@@ -56,6 +57,7 @@
python_requires=">=2.7,!=3.0,!=3.1,!=3.2,!=3.3",
install_requires=[
'setuptools',
'wrapt ~= 1.10',
] + (['subprocess32 ~= 3.2.7'] if version_info.major < 3 else []),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to this pull request, but why is setuptools here? The whole setup.py file requires setuptools to be installed already. And is subprocess32 really needed? Python 2.7 has subprocess.check_output or does it not work as expected? In any case it should be moved to extras_require as it is only needed for socketcan.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setuptools package is added for completeness, it is not exactly wrong that it is an dependency. It doesn't really help with anything though. Shall we remove it or leave it? I think it doesn't really matter.

Hm, I agree that subprocess32 should be moved into extras_require. But I added it as an dependency because of this note at the top of the documentation you linked:

POSIX users (Linux, BSD, etc.) are strongly encouraged to install and use the much more recent subprocess32 module instead of the version included with python 2.7. It is a drop in replacement with better behavior in many situations.

I simply followed that advice.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setuptools is not a dependency for the can module itself. It is setuptools that handles the the install_requires at setup time so it is a bit strange and I haven't seen any other packages do the same.

Have you tested if it works on Python 2.7 using the built-in subprocess module? If it does then it seems unnecessary to add an extra dependency. After all, it is a pretty simple function that is not critical.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll remove the setuptools dependency.

Lets's see what Travis CI will tell us about the built-in subprocess module ...

@felixdivo
Copy link
Collaborator Author

Okay, so it was possible to remove the subprocess32 module without any problems. This does not belong to the topic of this PR but is pushed here because the discussion has taken place in here.

@felixdivo
Copy link
Collaborator Author

Do you know why test/socketcan_helpers.py is never executed?

@christiansandberg
Copy link
Collaborator

It must contain “test” in the filename.

doc/bus.rst Outdated
---------------

This thread safe version of the bus class can be used by multiple threads at once.
Sending and receiving is locked seperatly to avoid unnessesary delays.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd mention that a call from one thread will block until the bus is free - rather than an async approach using a threadsafe queue.

@felixdivo
Copy link
Collaborator Author

@christiansandberg

It must contain “test” in the filename.

Now it works. Thanks!

@hardbyte
Is the documentation now sufficient?

@felixdivo felixdivo added this to the 2.2 Release milestone Jun 8, 2018
@felixdivo
Copy link
Collaborator Author

Shall I merge it?

@hardbyte
Copy link
Owner

:shipit:

@felixdivo felixdivo merged commit bb3b117 into develop Jun 13, 2018
@felixdivo felixdivo deleted the feature-synchronized-bus branch June 13, 2018 19:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants