Patterns for dealing with the asynchronous nature of Pony. Unlike most languages, Pony has zero blocking operations. This can make simple everyday problems difficult until you know how to deal with them. If your problem has you wanting blocking operations, this is the chapter for you.
Problem With asynchronous APIs on actors, we have the problem of not being able to combine multiple asynchronous calls to form an atomic operation, as messages to an actor may be interleaved. This means that any operation that isn’t exposed as a single behaviour on the actor cannot be done in an atomic way, which puts a pressure on our API to provide “ancillary” behaviours that are just combinations and compositions of the “fundamental” behaviours.
Problem Pony gives us an excellent abstraction for actors. We can define fields within those actors to maintain state and rely on the single-threaded nature of inbound message processing to ensure safe access to those fields. A problem arises when one actor wants to access the internal state of another actor.
Let’s say that you want to collect values obtained from multiple actors without having to create a giant state machine.
Problem Here’s the problem: you’re writing an application that needs to execute an action every few seconds. In a language with blocking operations, I could just call sleep and be done with it. It might not be the most elegant solution but it would work. In Pony, no such obvious solution exists. One of Pony’s key features is there are no blocking operations. It’s a bit of a riddle: how do you wait when you can’t wait?