Client background thread doesn't stop after Timeout

[goyzhang]

If I am right there are some background threads/tasks to handle incoming message. While I am calling :

try:
    v = sio.call('get_v, 'data',  timeout=5)
except socketio.exceptions.TimeoutError as e:
    print("error")
finally:
    sio.disconnect()
#main thread exit here, but the python process doesn't

Assume that the sever will return after 10s, I will have to wait for 10s with or without sio.disconnect() for the python process to end. It seems some background threads are preventing the process from terminating. In case of timeout, why does it have to wait? Or is there anyway to abort those non-daemon threads?

I'm running the latest client on a windows PC.

[miguelgrinberg]

I adapted one of the examples in this repository to do what you are doing, and I don't really see this problem. My client exits after 5 seconds.

If you can provide your logs that might help me understand how your case is different than the test that I built here. See the Troubleshooting section of the docs if you don't know how to enable logs in your client.

[goyzhang]

Hi @miguelgrinberg , I tried again, both client and sever on windows, but still the same result, could you check: gist
Here is my output from the client:

04:48 : call()
04:49 : timeout throw
04:49 : disconnect()
04:58 : end, process end

see it hangs for 9 seconds after 1 seconds timeout.

Logs enabled:

Attempting polling connection to http://localhost:5000/socket.io/?transport=polling&EIO=4
Polling connection accepted with {'sid': 'SQ0HN5Uw9UNYJzKgAAAO', 'upgrades': ['websocket'], 'pingTimeout': 20000, 'pingInterval': 25000}
Engine.IO connection established
Sending packet MESSAGE data 0
Attempting WebSocket upgrade to ws://localhost:5000/socket.io/?transport=websocket&EIO=4
WebSocket upgrade was successful
Received packet NOOP data
Received packet MESSAGE data 0{"sid":"ihXf3eLEUAqJb-YWAAAP"}
Namespace / is connected
12:29 : call()
Emitting event "get_data" [/]
Sending packet MESSAGE data 21["get_data","data"]
12:30 : timeout throw
12:30 : disconnect()
Sending packet MESSAGE data 1
Sending packet CLOSE data None
Engine.IO connection dropped
Exiting write loop task
Unexpected error decoding packet: "string index out of range", aborting
12:39 : end, process end
Waiting for write loop task to end
Exiting read loop task

It could have some relation to the flask-socketio server...But I guess even so the client shouldn't suffer from it?

[miguelgrinberg]

You can't use time.sleep() in an async application, as it blocks the async loop and prevents the communication with clients. The issue was not that the timeout blocked, the problem is that the client is waiting for a response to the disconnect, and the server is unresponsive because of the blocking sleep. Replace the sleep with socketio.sleep() which is async compatible.

[goyzhang]

OK, in fact I have no control over the server. The sleep is just for demo, both server and client are sync app, in practice, it accesses some hardware resource sync. The problem is my client just can't exit after timeout, even when the main thread ends. if I remove disconnect, and the main thread reaches the end, then the python process freezes. Is there any way to configure the daemon thread to just let it die after the main thread ends? (even the CTRL+C trick doesn't work)

(btw it feels weird that clients have to wait for a response for disconnection, it may try and just force disconnect instead of waiting, here its 10s, what about 100s? if the server doesn't respond then the client freezes on disconnect forever? Maybe there are some design considerations behind this)

[miguelgrinberg]

@goyzhang a graceful disconnect is not an atomic operation, it requires first disconnecting the namespace(s) you are connected to, and then disconnecting the base Engine.IO connection. I have not added a "force" option to disconnect, but I think that makes sense to avoid depending on servers that aren't responsive.

So I'm going to use this issue to track this enhancement. Thanks.

[miguelgrinberg]

I'm still unable to reproduce this delay with the provided code examples, so I'm going to close.