4 ms·

> I guess one big question here is whether there's a higher layer abstraction that is available to wrap around patterns to avoid this. Something like Actors, o

> I guess one big question here is whether there's a higher layer abstraction that is available to wrap around patterns to avoid this. Something like Actors, on top of Tokio, would be one way: https://ryhl.io/blog/actors-with-tokio/ https://ryhl.io/blog/actors-with-tokio/

smallstepforman 1y ago
I love Actors and have used them professionally for over 6 years (C++). However to solve real world problems I have had to introduce “locks” to the Actor framework to support various scenarios. With my home-grown actor library, this was trivial to add, however for some 3rd party actor libraries, ideology is dominant and the devs refuse to add such a purity-breaking feature to their actor framework, and hence I cannot use their library for real-world code.
- eklavya 1y ago
  That sounds interesting, what kind of actor use cases would require adding locks to actors?
- logicchains 1y ago
  What scenario requires locks that can't be solved by just having a single actor that owns the resource and controls access?
  - rtpg 1y ago
    I would imagine that in... "soft realtime" might be much but in performance sensitive scenarios the actual cost to having some coordination code in that space might start mattering. Maybe actor abstractions end up compiling away fairly nicely in Rust though!
  - smallstepforman 1y ago
    Any scenario where you have to atomically update 2 actors. To use a simple analogy for illustrative purposes, transferring money between 2 accounts, you need to lock both actors before incrementing/decrementing. Because in the real world, the accounts can change from other pending parallel transactions and edits. Handshakes are very error prone. Lock the actor, do the critical transaction, unlock. In a rationale world, this works. In a prejudiced world, devs fight against locks in actor models. Hence why I had to roll my own …
gf000 1y ago
Then you just replace deadlocks with livelocks, the fundamental problem AFAIK can't be avoided.

smallstepforman 1y ago

I love Actors and have used them professionally for over 6 years (C++). However to solve real world problems I have had to introduce “locks” to the Actor framework to support various scenarios. With my home-grown actor library, this was trivial to add, however for some 3rd party actor libraries, ideology is dominant and the devs refuse to add such a purity-breaking feature to their actor framework, and hence I cannot use their library for real-world code.

eklavya 1y ago
That sounds interesting, what kind of actor use cases would require adding locks to actors?
logicchains 1y ago
What scenario requires locks that can't be solved by just having a single actor that owns the resource and controls access?
- rtpg 1y ago
  I would imagine that in... "soft realtime" might be much but in performance sensitive scenarios the actual cost to having some coordination code in that space might start mattering. Maybe actor abstractions end up compiling away fairly nicely in Rust though!
- smallstepforman 1y ago
  Any scenario where you have to atomically update 2 actors. To use a simple analogy for illustrative purposes, transferring money between 2 accounts, you need to lock both actors before incrementing/decrementing. Because in the real world, the accounts can change from other pending parallel transactions and edits. Handshakes are very error prone. Lock the actor, do the critical transaction, unlock. In a rationale world, this works. In a prejudiced world, devs fight against locks in actor models. Hence why I had to roll my own …

gf000 1y ago

Then you just replace deadlocks with livelocks, the fundamental problem AFAIK can't be avoided.