Repository navigation
It would be nice if unbind() from another thread could interrupt run() #85
Description
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.
Activity
DOWRIGHTTV commentedon Apr 17, 2022
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 commentedon Apr 19, 2022
@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 runningunbind()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 commentedon Oct 6, 2023
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
runfunction is running on a daemon thread.Just curious, have you tried closing the socket in your
unbindfunction as a way to interrupt the blockingrecvcall?Thanks for this great library!
oremanj commentedon Oct 6, 2023
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.