The atom implementation changed with 0.18. The "Atoms" section in the manual explains how to use them: https://actor-framework.readthedocs.io/en/stable/MessageHandlers.html#atoms They are defined in the type id block of your application. (Don't forget to load it, e.g., like this).
Feel free to make a feature request on GitHub. :)
Here's a longer answer to a similar issue: https://stackoverflow.com/questions/70353846/segmentation-faults-when-testing-typed-actors-with-custom-atoms
i didnt see any discussion of that method, or the passing of arguments in the docs, but i didnt read them very closely either
and on closer inspection i see it
If I have an actor behavior that takes a parameter by reference, would it theoretically be safe to store that reference elsewhere if I also manually keep a reference count to the current message as long as I keep the reference? How would I go about getting a strong reference to the current message from a "self" pointer?
It is for read-only access purposes, thanks! Not sure if you've seen my discussion comment regarding coroutines w/ CAF result (open to chat about it any time!), but I kind of need to extend the current message lifetime until the coroutine frame is destroyed because by-reference function parameters are only stored by-reference in the coroutine frame.
I've seen the notification, I'll get back to that if I can make the time. Are you still on 0.17? In that case it's a bit more complicated. Because in 0.17 CAF can fuse the content into the mailbox element itself. You could do something like
self->current_mailbox_element()->move_content_to_message() to have something to hold onto.
But that of course invalidates the original reference.
Yeah we sadly still are. The upgrade had to move back due to limited engineering resources. We still have some stuff serialized with the
caf::binary_serializer, and the output of that changed between 0.17 and 0.18, so we're in the process of transitioning our database state in a forward-compatible way.
Invalidating the original reference is not a problem as I need to have a lifting function around every behavior callback anyways, I can move it in there. Thanks!
Totally separate question:
self->set_down_handler(...);
auto handle = self->spawn<caf::monitored>(my_typed_actor, args...);typed_actor<...>::behavior_type my_typed_actor(typed_actor<...>::pointer self, Args... args) {
if (!validate(args...)) {
self->quit(make_error(...));
return typed_actor<...>::behavior_type::make_empty_behavior();
}
return {
// ...
};
}If the validation inside the my_typed_actor function fails the down handler will never be triggered, despite the actor shutting down correctly. Is this a bug, or are we simply abusing the API here?
The general advise we give is preferring small messages. Utilizing bandwidth shouldn't be an issue, but if you force the middleman to serialize KB or even MB worth of data it will 'block' him for quite a bit. So you could see latency spikes from such 'jumbo messages'. I'd say build a small prototype and measure how much latency you actually cause. The Prometheus metrics for the middleman should give you a good idea. Limiting the arrow tables to some reasonable size could also be a good idea if that's reasonable for your application.
Thanks for your advice. For serialization of middleman, as Arrow provide built in serialization methods, I call it inside
inspect. So I guess the middleman can just transfer the serialized bytes from Arrow API, without incurring the serialization latency inside the middleman itself. May I know if this is true? But yeah for sure I will benchmark a bit to see the real effect. :)
CAF usually starts more threads than cores since slightly "overbooking" the system usually results in better performance. Some threads invariably have to wait at some point (e.g. due to memory access) and the extra threads can fill the gaps. The analogous abstraction to green threads in CAF are the actors, they all share a single thread pool for execution. The size of that thread pool can be configured with the parameter
caf.scheduler.max-threads (https://actor-framework.readthedocs.io/en/stable/ConfiguringActorApplications.html).
Ah nvm, just came across
caf::async::{consumer,producer}_resource<T>. That neatly solves what I wanted to do.
There's also some documentation available, btw.
Just do
sphinx-build in the manual directory and you'll have the version that has some initial documentation for the new flow API. :)
Or take the zip file.
I see. I can see how a new stream<T> built on-top of data flows can work much better than the existing streaming API, which was a pain to debug and had lots of shutdown order issues.
If I understand data flows correctly they must be fully configured before their hosting actors launch. This is a limitation compared to the existing experimental streaming API which was fully configurable externally, and integrated into the typed actor API. Will this limitation also exist for the new stream<T>? I'm curious about your plans on the streaming front in general.
And, yeah. The old streams are going away for a reason. ;)
Nvm, it actually can do the first one eagerly, that issue only occurs with at least three observables
Currently just trying to get a feel of the API and what it's use cases and limitations are, so I started by comparing it to how we use the current streaming APIs. Kinda excited to toy around with it. I assume the new streaming stuff on top of it is all targeted for CAF 0.19?