Skip to content
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

upgrading from threading to multiprocessing #5

Open
2bndy5 opened this issue Sep 25, 2019 · 0 comments
Open

upgrading from threading to multiprocessing #5

2bndy5 opened this issue Sep 25, 2019 · 0 comments
Assignees
Labels
apprentice this opportunity is for those looking for a challenge bug Something isn't working enhancement New feature or request help wanted Extra attention is needed master wizard this opportunity is not for beginners

Comments

@2bndy5
Copy link
Owner

2bndy5 commented Sep 25, 2019

all the following code references assume myThread = threading.Thread(target=func_pointer) where func_pointer is the function that is executed by the myThread object once myThread.start() has been called. NOTE: func_pointer() is the functionality we want to reuse to smooth acceleration/deceleration on the drivetrain/motor object(s).

As it turns out, myThread.join() will block until the thread is considered "not alive" which can be determined as a bool by calling myThread.is_alive(). If we pass a timeout value to join(timeout=5.5), then the function will only wait for the myThread has finished for a up to 5.5 seconds. This does not mean the thread is finished if the timeout has been reached, rather the thread is still busy and join gave up on waiting for it to finish. Despite wheather the thread is alive or not, to execute a threaded func_pointer(), the func_pointer needs to be passed again as the target parameter to newThread = threading.Thread(target=func_pointer) object (and initiated with newThread.start() function). This is problematic since both threads can be executing simultaneously instead of aborting previous thread and re-start()-ing in under the newThread's context. Using the threading module's context managers -- like using with statements -- won't solve this either because they only care about what main program "owns" the thread.

Furthermore, threads only get cleaned up or deleted when the main python program exits (to the best of the interpreter's ability -- see the paragraph about "dummy/alien threads" just above this link). This is why we need to better manage the threads that are created.

Enter the multiprocessing module... More on this when I get my hands dirty. As it is the drivetrain is stable, so I'll be starting a new branch to do some preliminary tests.

@2bndy5 2bndy5 added bug Something isn't working enhancement New feature or request help wanted Extra attention is needed labels Sep 25, 2019
@2bndy5 2bndy5 self-assigned this Sep 25, 2019
@2bndy5 2bndy5 added apprentice this opportunity is for those looking for a challenge master wizard this opportunity is not for beginners labels Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apprentice this opportunity is for those looking for a challenge bug Something isn't working enhancement New feature or request help wanted Extra attention is needed master wizard this opportunity is not for beginners
Projects
None yet
Development

No branches or pull requests

2 participants