by 12_throw_away
5 subcomments
- No, determinstic scheduling is not a property of async python.
Yes, the stdlib asyncio event loop does have deterministic scheduling, but that's an implementation detail and I would not rely on it for anything critical. Other event loops - for instance trio [1] - explicitly randomize startup order so that you won't accidentally write code that relies on it.
[1] https://github.com/python-trio/trio/issues/32
- That's deterministic dispatch, as soon as it forks or communicates, it is non deterministic again?
Don't you need something like a network clock to get deterministic replay?
It can't use immediate return on replay, or else the order will change.
This makes me twitchy. The dependencies should be better modelled, and idempotency used instead of logging and caching.
- Is this guaranteed by the async specification? Or is this just current behavior which could be changed in a future update. Feels like a brittle dependency if its not part of the spec.
- While not production ready, I’ve been happily surprised at this functionality when building with it. I love my interpreters to be deterministic, or when random to be explicitly seeded. It makes debugging much easier when I can rerun the same program multiple times and expect identical results.
by annexrichmond
0 subcomment
- This reminds me of this great talk from Temporal about how they built their Python SDK by creating a distributed deterministic event loop on top of asyncio[1]
[1] https://www.youtube.com/watch?v=wEbUzMYlAAI
by lexicality
3 subcomments
- > This makes it possible to write simple code that’s both concurrent and safe.
Yeah, great, my hello world program is deterministic.
What happens when you introduce I/O? Is every network call deterministic? Can you depend on reading a file taking the same amount of time and being woken up by the scheduler in the same order every time?
by Sim-In-Silico
0 subcomment
- [dead]
Hacker News