python3 lirc.nextcode() seems to block even when blocking set to False

[VengefulPikachu]

Wrote very short program to demonstrate this:

import lirc
import time
sockid = lirc.init("python3", ".lircrc". blocking=False)
while True:
    try:
        button = lirc.nextcode()
        print("Looped!")
        if len(button) == 0: continue
        print(button[0])
        time.sleep(1)
    except KeyboardInterrupt:
        lirc.deinit()
        break

This should print "Looped!" every second, and also print the button pressed otherwise. But the program stops (is blocked) at the nextcode() line until a button is pressed. It then passes on the button, and a handful of zero length returns, then goes back to blocking.I've also tried with the separate "set_blocking" line. I can see in the code where it is supposed to set the O_NONBLOCK flag, so maybe it's a bug in LIRC? I'm really new to python, so if I'm misunderstanding something, just let me know please.

[VengefulPikachu]

To make matters more confusing, it seems to somehow be blocking all other threads in my python program as well. Every thread seems to be put on hold unless I hold down a button on the remote. I'm sure this isn't on purpose.

[tompreston]

There was a bug with the set_blocking function. I've pushed a fix to the testing branch and it seems to work. Can you test this and then I'll push it to the master branch.

Thanks.

[VengefulPikachu]

I'll give it a try, thanks!

edit: Um... still trying to figure out how to download the testing branch. I found a link to get a zip file... I'll figure it out soon...

edit2: Looks like it is working. I need to play around in my program, remove my work arounds, to be sure but I think it is behaving the way I'd expect it to.

[tompreston]

To get the testing branch:

git clone https://github.com/tompreston/python-lirc.git
cd python-lirc/
git checkout testing
git pull origin testing

Also, Python can't really do threads: "In CPython, due to the Global Interpreter Lock, only one thread can execute Python code at once"

[VengefulPikachu]

Yeah, I'm using sleeps and loops to give other threads time to execute. While active, each thread should still be spending 95% of it's time sleeping, which gives the other threads time to poll their stuff and go back to sleep. The only lock I have is a split second when the led changes color. This should let it handle a bunch of inputs at once even if it hasn't had a chance to send all of the commands yet.

I may try rewriting it another way later and see which works better in practice.

[tompreston]

Ok cool. I'll merge the change into master, thanks for your help.