-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
ev3dev: cache invariant values for motors #53
Comments
@dlech A question about behaviour of |
These will never be zero length. (But even if they were, you would still probably get a newline.) |
I'm not sure what I was thinking when I wrote some of the test code, but that is fixed now. |
If it was up to me, I would also cache the mode-specific values of sensors when you set the mode. |
I can understand the motivation behind this, but I am concerned about values going stale in normal operation. I am probably being overly cautious here. The current situation does not prevent users from having more than one handle per device, which means that different goroutines may have different ideas about what is happening with the underlying device if the value is cached. An approach to deal with that is to prohibit having more than one handle per physical socket. This complicates the device opening code, but is achievable with a global mutex-protected map of port identifiers to |
Another alternative is to have a global mutex-protected map to a struct that holds the cached values and the device identifier - if the device ID does not match a querying device then the value is invalid. This feels more brittle to me though, and does not get rid of the |
See ##50 (comment).
not handled at the motor level -address
AddressOf
provides thiscommands
count_per_rot
count_per_m
full_travel_count
driver_name
max_speed
stop_actions
The text was updated successfully, but these errors were encountered: