Open oremanj opened 2 years ago
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?
@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.
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!
Unfortunately close() doesn't interrupt a read() on the same fd in another thread. I did some research and found https://github.com/python-trio/trio/issues/174#issuecomment-314939704 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.
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.