Error when recreating sockets

[davidbrochart]

In jupyter-server/jupyverse#619 I added a test that (sometimes) fails on asyncio but never on trio, so I'm suspecting a bug either here or in anyio.
The test repeats the following:

• create a kernel
• connect to it using sockets
• stops the kernel
• disconnect sockets

The error is: zmq.error.ZMQError: Socket operation on non-socket. I could not reproduce it in zmq-anyio so I'm getting out of ideas, @graingert does is ring a bell?

[graingert]

Probably worth cc-ing @agronholm

[agronholm]

So what's the non-socket in question?

[davidbrochart]

Thanks for chiming in, I don't want to waste your time though, as I'm not sure it's something wrong on my side.
I'm not sure what is going on, here I get a anyio.BusyResourceError: Another task is already reading from this resource on asyncio, and a zmq.error.ZMQError: Socket operation on non-socket on trio.
I suspect an error in how zmq-anyio cleans up the socket. I should manage to reproduce the bug here though, that would eliminate other source of bugs.

[davidbrochart]

I might have a reproducer in #36.

[davidbrochart]

Gemini suggested this fix with the following explanation:

✦ I have fixed the bug where rapidly creating and closing zmq_anyio.Socket instances could lead to ENOTSOCK errors due to libzmq handle reuse.

The fix involved:

1. Ensuring double-closure prevention: Modified Socket.close() to explicitly close the internal _shadow_sock. This ensures that the underlying libzmq handle is marked as closed in both Python objects, preventing the garbage collector from accidentally closing a reused handle when the original object is destroyed.
2. Instance-level attribute initialization: Moved class-level attributes to the init method to prevent potential state leakage between different Socket instances.
3. Correcting loop conditions: Updated the _start loop to correctly handle fd=0, which is a valid signaling FD in libzmq.