This repository was archived by the owner on Nov 19, 2020. It is now read-only.
Repository navigation
Mark call to lirc_client.lirc_nextcode(...) as nogil - #17
Merged
Merged
Conversation
…ng it would block all threads in our python program
tompreston
approved these changes
Oct 24, 2017
Owner
|
Hey I don't have any IR hardware to hand at the minute. Can you write a test showing how this works for someone else to have a look? Otherwise I might be able to take a look tomorrow. |
Author
|
The following class is the simplified version of what I use in my project. It uses blocking wait in a separate thread. As |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I had some problems using python-lirc: every time I called
lirc.nextcode()(with blocking mode activated, because without blocking it makes busy-waiting which is pretty bad) in my python3 script, my whole program stopped working, even if I did this in a separate thread.While debugging the problem I learned about the "biggest problem of python" (the GIL) and how complicated python multi-threading is because of it.
As the problematic call is a native one from the lirc client library I assume that it is ok to mark it as
nogil, when using onlycdef(hence no-Python?) variables.With the changes in this pull request I was able to create a separate python thread that calls
lirc.nextcode()in a loop that effectively did not had any effect on the MainTread regarding blocking the GIL.However I have to admit that my cython experience is very little. Hence that it works for me doesn't mean that it actually works without problems on all platforms. May be a more experienced cython programmer should look at the code and say if it is ok the way I changed it.
But as blocking the GIL has such a bad impact I thought that a non-GIL-blocking version of python-lirc would be useful for everybody.