Behavior-Oriented Concurrency for Python
mpweiher
67 points
9 comments
May 06, 2026
Related Discussions
Found 5 related stories in 79.5ms across 8,303 title embeddings via pgvector HNSW
- Async Python Is Secretly Deterministic KraftyOne · 69 pts · April 03, 2026 · 48% similar
- Process-Based Concurrency: Why Beam and OTP Keep Being Right linkdd · 96 pts · March 02, 2026 · 46% similar
- PyTheory Is Awesome zdw · 14 pts · March 25, 2026 · 42% similar
- Moving from Python to Mojo tosh · 11 pts · March 07, 2026 · 40% similar
- Bun: cgroup-aware AvailableParallelism / HardwareConcurrency on Linux tosh · 41 pts · April 03, 2026 · 40% similar
Discussion Highlights (5 comments)
hanselot
Is it just me or is the example they use for the locking extremely badly implemented? Why would one ever result at that methodology?
krystalgamer
the example is atrocious, seems like erlang actor model but for python.
chombier
I was a bit curious to learn what the differences are between this and the actor model, and I found this lobste.rs discussion to be helpful: https://lobste.rs/s/gsjskz/behavior_oriented_concurrency_for > In BoC, the equivalent of a message is received by multiple actors and operates with exclusive access to the message and all of the receivers. (emphasis mine) IIUC with actors, messages are processed by exactly one actor so it can be difficult to express transactions (e.g. transferring funds from A to B cannot be done atomically). Erlang somewhat fixes this with "selective receive" which re-introduces the possibility of deadlocks. BoC fixes both issues.
vivzkestrel
- stupid question: what is different about this concurrency compared to say asyncio?
traderj0e
Was wondering how this is using a separate GIL per action when the actions are pure Python code. "PEP 684 introduces a per-interpreter GIL, so that sub-interpreters may now be created with a unique GIL per interpreter."