# \[ANN\] YAActL 0.2, Yet Another Actor Library (built in Julia)

**URL:** <https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637>\
**Category:** Package Announcements\
**Tags:** multithreading, concurrency, actors\
**Created:** [October 19, 2020, 4:04pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637 "2020-10-19T16:04:28Z")\
**Posts on this page:** 4\
**Page:** 3

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [November 11, 2020, 3:45pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/41 "2020-11-11T15:45:20Z")

</div>

> [@tisztamo](#):
>
> YAActL heavily uses blocking operations on channels

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:

1. `put!` a message to an actor into its channel,
2. … the actor task then is switched to, `take!`s the message from the channel, and `put!`s something into a response channel,
3. 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.

> [@tisztamo](#):
>
> I fear that we will get no performance gain if we simply implement a channel-like interface over Circo

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.

---

<div class="post-metadata">

**Author:** ![tisztamo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tisztamo/32/16200_2.png) [@tisztamo](https://discourse.julialang.org/u/tisztamo)\
**Post date:** [November 11, 2020, 5:15pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/42 "2020-11-11T17:15:29Z")

</div>

Thanks for clarifying, I will check the code again!

A full ping-pong in 800 ns is not bad, especially that you get the convenience of blocking in the actor. Hopefully the scheduler will be even faster in the future.

---

<div class="post-metadata">

**Author:** ![pbayer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbayer/32/11675_2.png) [@pbayer](https://discourse.julialang.org/u/pbayer)\
**Post date:** [November 11, 2020, 5:57pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/43 "2020-11-11T17:57:00Z")

</div>

> [@tisztamo](#):
>
> I will check the code again!

look for the `_act(A::_ACT, msg::Message)` finite state machine in [`actors.jl`](https://github.com/JuliaActors/YAActL.jl/blob/master/src/actors.jl). This will become something like `onmessage(A::_ACT, msg::Message)` in `Actors.jl`, our new interface library. You can then plugin/reimplement that one. You have to provide it with the variable `A::_ACT`. You can realize that with a function barrier dispatching on `Message`.

We can try soon. 😉

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [November 11, 2020, 10:43pm UTC](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637/44 "2020-11-11T22:43:35Z")

</div>

I’m watching YAActl.jl to see how its redundancy story plays out, but for right now Dagger needs time to develop and mature. Once I feel like it’s ready, I’d be very interested to look at YAActl again to see if it can be used to implement fault tolerance and supervisory behaviors in a way that doesn’t inconvenience users of Dagger.

[Previous page](https://discourse.julialang.org/t/ann-yaactl-0-2-yet-another-actor-library-built-in-julia/48637.md?page=2)