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

Use a different startmethod for curses comaptibility #9

Open
AiyionPrime opened this issue Dec 7, 2021 · 0 comments
Open

Use a different startmethod for curses comaptibility #9

AiyionPrime opened this issue Dec 7, 2021 · 0 comments

Comments

@AiyionPrime
Copy link

Currently this project uses the multitprocessing module and makes use of Process(), which are started using start().

self.p = Process(target=self.pwm_process, args=(self.gpio, self.sleep_high, self.sleep_low, self.precision), name='pwm_process')
self.p.start()

This does invoke one of the three different startmethods of multiprocessing implicitely.
https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods

Apparently one of the forking kind.
This leads to an incompatibility with curses, as screen properties are reset, when a (forked) child process exits.
Which means, everytime a PWM stop()s, curses screen does all sorts of stuff.

This project would not invoke such unwanted side effects, if started processes where spawned instead of forked.
In documentation a few lines below the above reference https://docs.python.org/3/library/multiprocessing.html#multiprocessing.set_start_method is documented.

@Leapo Would it be possible to use it instead of the implicit behavior?

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

No branches or pull requests

1 participant