>>>> [...] any stem-application will, for instance, notice that Tor closed
>>>> its control port on the next send() or recv() on the socket, and then
>>>> throw a stem.SocketClosed.
>
> i.e. it will not immediately notice that Tor has closed the socket. I
> don't see why it should be any different when a stem-application is
> connecting to the filter instead. I'm not sure why this is the case, but
> my bet would be that it's related to how stem does async IO.
Yes and no. Stem doesn't know that the socket is closed until it tries
to use it, *but* Stem is always listening to the socket. So Stem knows
right away when the socket is closed.
https://stem.torproject.org/api/socket.html#stem.socket.ControlSocket.is_alive
OnionShare can call the is_alive() method to determine if the
connection is still around or not. Could the filter perhaps be failing
to call close() on its sockets? Shouldn't matter (assuming it's python
GC should be taking care of that), but good practice to be sure.
