YAActL doesn’t block if it processes a message – as it should be. It runs each message to completion before it eventually take!s the next message from the channel. This then blocks, switches the task and is indeed costly. A complete communication cycle is:
put!a message to an actor into its channel,- … the actor task then is switched to,
take!s the message from the channel, andput!s something into a response channel, - then you
take!it from the response channel
This takes about 0.8\, μs on my machine. Thereby it doesn’t matter much if the communication goes to another thread. BTW this is still faster than @spawn-ing a task and fetch-ing the result. This is the price to pay if we build on Julia’s concurrency primitives. Therefore the stuff we do with actors must not be too lightweight and then actors building on Julia’s scheduler have still their place and I hope that scheduling times will improve.
You don’t have to fear anything since this is not necessary. Actors are not bound to channels. There must be only a mechanism to trigger the actor machinery if a message arrives. If you have another faster scheduler and message delivery mechanism, you use that as trigger.
On blocking: I was surprised to see that Erlang/Elixir uses blocking often deliberately to simplify things. I adopted somehow their philosophy: you can choose to work asynchronously without blocking (and process a response later) or synchronously with blocking. I also liked their mechanism that you can set a timeout on blocking and implemented it. You also can use a timeout of 0 to scan the inbox for messages of a given type or sender.
