3 ms·
Actors aren't just about distributed state, they're about any state that could be accessed or modified concurrently. Distributed systems don't have to come int
by saryant 12y ago
Actors aren't just about distributed state, they're about any state that could be accessed or modified concurrently. Distributed systems don't have to come into play for actors to be useful. Actors provide a sane way to deal with mutable state with potentially multiple readers or writers.
- DanWaterworth 12y agoHaving used STM in Haskell, actors look like a draconian way to handle shared mutable state.
- lomnakkus 12y agoExactly! Unless you're hitting actual trouble with contention (or some such), there's absolutely no reason to be programming as defensively as we must do in distributed systems.
- DanWaterworth 12y agoIf you have problems with contention, you can use a library like this [1], that allows you to perform transactions (with the restriction that you must know the variables you may touch ahead of time) without deadlocking or livelocking. [1] https://hackage.haskell.org/package/blocking-transactions https://hackage.haskell.org/package/blocking-transactions
- lomnakkus 12y agoAny state that could be accessed or modified concurrently is effectively distributed (in the Actor model). (If not over the network, then over multiple CPUs communicating over a bus which may require memory barriers.) Unfortunately the model mandates that you must either a) implement ALL of your cohesive/non-concurrent state in "one actor per unit of cohesion" or b) deal with state as if it's distributed. In other words: It's not a good tradeoff for typical programs. (Which I think is what my original comment said.) Don't get me wrong: If almost all your state is distributed, e.g. Riak, then I'm sure it's a fine way to do things. Let's just avoid the "works-for-them-It's-sure-to-work-for-us" pitfall.