Remove stack allocated lock acquisition

[ccp-serpent]

This change should not affect behavior. These locks aren't declared outside stack scope so there is no means by which another thread could attempt to acquire the same lock.

Summary

AI assistance disclosure

None

Type of change

• Bug fix
• New feature
• Refactor / cleanup (no behaviour change)
• Documentation
• Build, CI, or tooling
• Breaking change (public API or ABI)
• Other (describe below)

Linked issue (optional)

No linked issue. But a question was brough up here which resulted in this work.

What changed

• Removed stack allocated lock acquisition in QueueChannel objects.

Testing

• The changes are covered in unit tests and passed successfully in a local environment. No further tests were added.

Platforms tested

• Windows
• macOS
• Not applicable

Screenshots / captures

Checklist

• I've read CONTRIBUTING.md.
• My commits follow the commit-message style described there.
• I've added or updated tests where it made sense.
• I've updated docs / inline API comments for any behaviour change.
• My CLA / ICLA is signed (the bot will let you know if it isn't).

---

[CCP-Aporia]

Interesting! So, threading.Lock() was indeed wrong here. However, now the class is no longer thread-safe. A likely use case is that this kind of class is used to communicate between threads - a use-case that is supported by Stackless' channel implementation. Without any kind of lock - or with the previous stack-based lock - then this is going to cause data races.

[ccp-serpent]

Interesting! So, threading.Lock() was indeed wrong here. However, now the class is no longer thread-safe. A likely use case is that this kind of class is used to communicate between threads - a use-case that is supported by Stackless' channel implementation. Without any kind of lock - or with the previous stack-based lock - then this is going to cause data races.

Don't python threads require a GIL acquisition? If so, there can only ever be a single thread executing python bytecode at any time.

https://docs.python.org/3/library/threading.html#gil-and-performance-considerations

I can see a case where we might want to add a locking mechanism here for free-threaded builds.