It would be nice if unbind() from another thread could interrupt run()

[oremanj]

This seems to be a common user request, e.g., see #42.

At the kernel level we probably need to send some kind of no-op request on the queue in order to produce a response that run() will read. Then once we've confirmed that run() has exited, we can actually unbind. Unclear whether libnetfilter_queue exposes enough rope to do this.

[DOWRIGHTTV]

is this so you can bind/unbind multiple times in the same process or just to allow for the application to release its resources properly on exit?

[oremanj]

@DOWRIGHTTV it's to support pushing run() into a background thread (presumably using a queue of some sort to pass the packets to the main thread for processing), such as you might want in a GUI app. Currently there is no way to shut down the background thread if you do this. A few users have attempted to do it by running unbind() in the main thread, and complained when that doesn't work. It's somewhat difficult to support but I created the issue so the idea wouldn't get lost.

[philipbl]

I just ran into this problem! I would love if there was a fix for it. As a work around, I made the thread the run function is running on a daemon thread.

Just curious, have you tried closing the socket in your unbind function as a way to interrupt the blocking recv call?

close(fd)

Thanks for this great library!

[oremanj]

Unfortunately close() doesn't interrupt a read() on the same fd in another thread. I did some research and found python-trio/trio#174 (comment) that describes a much more convoluted way to interrupt a read() in another thread. The solution I sketched in the issue description is probably easier, but now we have more options... I'm unlikely to find time to implement this soon though.