Fix race conditions on loop._ready_len

[x42005e1f]

What do these changes do?

This is a simple PR that fixes MagicStack/uvloop#720 by removing loop._ready_len in favor of len(loop._ready). The attribute was probably added as a premature optimization (it does not affect performance even in edge cases), but it leads to race conditions both between worker threads calling loop.call_soon_threadsafe() and between any such worker thread and the event loop, since loop._ready_len is updated in a non-thread-safe manner (free-threading).

Are there changes in behavior for the user?

Since the attribute is not public (and according to GitHub search, it has never been used by anyone else), no.

Is it a substantial burden for the maintainers to support this?

No, this PR mirrors MagicStack/uvloop#721.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes

[Vizonex]

@x42005e1f if some of these workflows fail know that it one of two cases

• There is a rounding bug that has yet to be patched over here but it's also been a known problem on uvloop's end.
• As for 3.14t windows 11 arm, The workflow appears to be broken and I don't currently know how to fix it.

If everything else passes I'll let this through without issue.

[Vizonex]

Interesting, seems either the optimizations on uvloop's end or my end did not work here.

[Vizonex]

@x42005e1f I'm gonna let this through now since all the wheels are being built successfully I'm on a pretty tight schedule today due to my part-time job but other than that I want thank you for patching this bug on both mine and uvloop's ends.