darkhaniop

Hi, I just ran some tests to try to understand how the (sync) connections are handled in WebSockets (I described one in [#1596](https://github.com/python-websockets/websockets/issues/1596#issuecomment-2778658923)). So, what about the server side? I...

Hi, I ran some tests, and I think that by running the WS client itself in a secondary thread (not the one handling interrupts), this race condition can be avoided....

Thanks for clarifying the issue. Indeed, I was testing ways of gracefully closing the WebSockets sync client running in a secondary thread. I noticed the delay (and exceptions) when closing...

Unfortunately, I couldn't reproduce this "delay." Before I explain what I did, let me confirm if I understood the bug correctly. When we call `connect()` (from `websockets.sync.client`): - a TCP...

BTW, here's a script I used to check this behavior: ```python import threading import time from websockets.sync.server import serve, Server class SharedRef: server: Server def server_target(shared_ref: SharedRef): def echo(websocket): for...

> Is there a real-world use case for this? Admittedly, I have not used it in my client scripts either (as in, never made my scripts check the closing message)....