You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed an issue that may be GIL-related. Let's say that a separate Python thread is spun up that periodically tries to connect to a server (e.g., run_client). Then, we call a blocking UMI read(). I think that the read() call will block other Python threads from running due to the GIL. However, it will never receive any data, because that is dependent on the client connecting in a separate thread! The main workaround I found is to use multiprocessing.Process instead of threading.Thread. However, I think this behavior is fairly non-intuitive. It would be great to figure out how to make the Python API more friendly to threading.
The text was updated successfully, but these errors were encountered:
I noticed an issue that may be GIL-related. Let's say that a separate Python thread is spun up that periodically tries to connect to a server (e.g.,
run_client
). Then, we call a blocking UMIread()
. I think that theread()
call will block other Python threads from running due to the GIL. However, it will never receive any data, because that is dependent on the client connecting in a separate thread! The main workaround I found is to usemultiprocessing.Process
instead ofthreading.Thread
. However, I think this behavior is fairly non-intuitive. It would be great to figure out how to make the Python API more friendly to threading.The text was updated successfully, but these errors were encountered: