-
Notifications
You must be signed in to change notification settings - Fork 23
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
init_hardware on a Child fails to start pigpiod due to threading problem #186
Comments
Ok I think I found the problem.
Workaround: add a pref called PIGPIOD and set it to "true". I would also propose that starting pigpiod should not be a side effect of initializing a hardware pin .. it should only be initialized when the Agent is booted. The current side effect doesn't work anyway because initializing hardware happens in a thread, and threads can't use "signal" (apparently). The only reason "signal" is being used is to connect a "kill" to pigpiod, but this doesn't seem to be working reliably anyway (we have to kill pigpiod on every autopilot restart). So we should probably just remove this use of signal ( autopilot/autopilot/external/__init__.py Line 85 in 04b5968
|
YES. that is extremely annoying. Making Prefs explicit is the thing I didn't have time to get to when switching over to formal data models for v0.5.0. The way it works now is bad for exactly this reason (not clearly documented, some prefs are implicitly accessed, etc.) related to : #155 Launching pigpiod as a byproduct of initializing a GPIO object is for the purpose of being able to use them outside of a task/agent context, which was a requested (and useful) feature, but pigpio is just a pretty fussy program generally and so yes we need a better way of killing the process. A better way of launching it than is done now (a function call with an implicit global module state) would be to have explicit process handling classes, just haven't had the time to implement yet. |
Having trouble initializing hardware on a Child Pi. As far as I can tell, the first time a GPIO is initalized, it creates a subprocess for pigpiod and stores it in a global variable PIGPIO_DAEMON, unless that global already exists, in which case it uses the existing value. Problem occurs because for some reason the
signal
line can't be executed in any thread except the main one, and I guess the Child task is being run in a thread? I do not get this problem on the Parent Pi.Seems like the fix is to call external.start_pigpiod() in the main thread on the Child, if I can figure out how to do that.
The text was updated successfully, but these errors were encountered: