actor-framework/chat

CAF: The C++ Actor Framework

Dominik Charousset

@Neverlord

It usually is a matter of not having the type ID block visible, but hard to tell without code.

Dylan Baros

@dylan-baros

I inherited this code so pardon my ignorance, but here is what they did, They used CAF_ADD_ATOM:

CAF_BEGIN_TYPE_ID_BLOCK(duck_msg_types, caf::first_custom_type_id)
CAF_ADD_ATOM(duck_msg_types, do_duck_behavior)
CAF_ADD_ATOM(duck_msg_types, display_behavior)
CAF_END_TYPE_ID_BLOCK(duck_msg_types)

Dylan Baros

@dylan-baros

@Neverlord I did not realize that you actually have seen this code before. I work at National Instruments where you have provided some support for a CAF based project. I posted my repo and question on stackoverflow and if you get a chance to look at it I would appreciate it. https://stackoverflow.com/questions/73901792/cant-compile-code-using-the-c-actor-framework-on-windows-using-cmake-works-o

patszt

@patszt

What is the proper syntax to pass std::vector<std::string> CLI arguments in 0.18.6?

--some-list-option=[\"a\"]

seems to work, but when i try to add the second entry
--some-list-option=[\"a\", \"b\"]
it fails with pec::invalid_argument.

This syntax is used in test/config_option_set.cpp

Used to work with just --some-list-option=a,b in 0.17.6

Dominik Charousset

@Neverlord

@dylan-baros I'll take a look over the weekend.
@patszt On the shell, you often have the problem that the shell is eating up the quotes. Did you try passing something like my_app '--my-list=["a", "b"]'?

1 reply

(note the single quotes around the whole --my-list argument)

Alexander Gagarin

@uentity

@Neverlord what's the expected timeframe for CAF 0.19 release?

Dominik Charousset

@Neverlord

@uentity working on the last major feature as we speak. :)
Plan is to release the first RC end of october.

Alexander Gagarin

@uentity

nice )

Dominik Charousset

@Neverlord

If you wanna keep track: https://github.com/actor-framework/actor-framework/milestone/18. #1347 is the last "big" feature.

Alexander Gagarin

@uentity

thanks for info!

Dominik Charousset

@Neverlord

Don't mention it. Sorry for the delay, originally, we've targeted mid-2022 for 0.19. But, you know how it is.. ;)

Alexander Gagarin

@uentity

@Neverlord perfectly know ) and you did amazing amount of work

Dominik Charousset

@Neverlord

Much appreciated, but it's not just me. 🙂
Even if most commits come from me at the moment, it wouldn't happen without discussions, feedback and testing from others that happens "behind the scenes".

Alexander Gagarin

@uentity

of cause, credits to all the team ) I see a lot of new API and useful features like websockets, etc. Fingers crossed it will be documented or described in articles =)

Dominik Charousset

@Neverlord

Yeah, the best feature is worth nothing without documentation. 😄

patszt

@patszt

@dylan-baros I'll take a look over the weekend.
@patszt On the shell, you often have the problem that the shell is eating up the quotes. Did you try passing something like my_app '--my-list=["a", "b"]'?

This works :) Thanks

Dominik Charousset

@Neverlord

👍

patszt

@patszt

void foo(typed_actor parent) {  
  auto spawned = parent->spawn(new_actor);
  parent->request(std::move(spawned), int{5}).then([]{});
}

is such function legal? It seems to me that the spawned actor may die and "then" will never be called. Is the lifetime somehow preserved here or are my worries justified?

Dominik Charousset

@Neverlord

The spawned actor won't terminate as long as there are still references to it. And it has a reference as long as it has messages in its mailbox. So this is fine.

patszt

@patszt

What if the request returns a not delivered promise? So we create a response_promise in the only message the spawned received. The response_promise is part of spawned state and we return it to response handle. Is the ref_count now 2? What happens to the response_handle once we exit this scope?

Dominik Charousset

@Neverlord

I don't understand what you are trying to say with "not delivered promise". The promises are actor-local and must not be visible outside of an actor. If an actor terminates before it fulfills a promise, it'll trigger a broken promise error message.

patszt

@patszt

Okay so the promise cannot be returned from the message handler?

But generally the request to spawned is supposed to create response_promise -> request to other actors- > deliver the promise once all actors respond to previous requests

Dominik Charousset

@Neverlord

The promises are a way to allow actors to respond at some later time to an input message. You can "return" a promise, but this only tells CAF to suppress the response message as the actor eventually sends one later.

patszt

@patszt

And it seems that by the end of foo function scope there is nothing to keep spawned alive. Is my assumption correct? I know that capturing spawned in the "then" clause should guard against it

Dominik Charousset

@Neverlord

Well, if you send a message, this message has a reference to its sender. So if your actor sends the message immediately, it'll live long enough to get the response message.

Did you look at https://github.com/actor-framework/actor-framework/blob/master/examples/message_passing/promises.cpp already? You could also spawn the worker in server_impl, which sound like a good approximation what you're trying to do?

Dominik Lohmann

@dominiklohmann

IIUC @patszt's problem correctly then the problem actually occurs when you return the response handle from his example function, because the response handle does not keep a strong reference to the destination actor. We ran into this when upgrading from CAF 0.17 to CAF 0.18 (yes we're finally getting to it), and were wondering if this was a change in behavior. The behavior we see is that a .then(...) on the response handle returned from this function was always replied to with a caf::sec::broken_promise. The requested handler of the destination actor always created a response promise.

Do you know if it's feasible to backport the CAF 0.18 response promise to CAF 0.17 to make this part of the transition easier?

Dominik Charousset

@Neverlord

What is the "destination actor" in your case? Let's say we have a communication pattern like A -> B -> C. A sends a request to B. B sends another request to C, holding onto a response promise. C responds normally.

B has a response promise, which holds a strong_actor_ptr back to A (https://github.com/actor-framework/actor-framework/blob/master/libcaf_core/caf/response_promise.hpp#L201). C has a message in its mailbox, so CAF should hold an implicit reference to it at least until it has responded. That's how I understand it. Where are my assumptions wrong?

Dominik Lohmann

@dominiklohmann

Consider this:

auto foo(event_based_actor* a) {
  auto b = a->spawn(B);
  return a->request(b,...); // uses a response promise
}

auto bar(event_based_actor* a) {
  foo(a).then(...); // always receives sec::broken_promise
}

This is essentially what we've encountered with CAF 0.18, and that same code worked fine in CAF 0.17, so we were wondering if anything changed in that regard.

Dominik Charousset

@Neverlord

So, A and C are long-lived and B only exists for the request? Let me see if I can reproduce B terminating in this case. This shouldn't fail with broken_promise from my understanding, because the message in C should keep B alive (first the request message in the mailbox of C itself and then of course the response message in B).

Dominik Lohmann

@dominiklohmann

There is no C in this at all, at least not in our example. It's just A and a short-lived B, where the response handle to the request to B outlives B and B uses a response promise for the request, and that causes us to receive a broken promise error in A when calling .then on the response handle.

We fixed this for now by returning a strong reference to B alongside the response handle and storing that in the lambdas passed to .then.

Dominik Charousset

@Neverlord

A repsonse promise cannot outlive it's actor. Or let me ask this way: who or what is supposed to deliver the promise in your case?

Dominik Lohmann

@dominiklohmann

Well, that's kind of our question: Isn't the response handle returned from foo supposed to keep b alive here? The code in question worked with 0.17, but doesn't with 0.18, hence the question. :D

Dominik Charousset

@Neverlord

Hm. Without code, I'm not quite sure how B is supposed to deliver its promise if it's not doing any messaging after that.

@dominiklohmann Different question. :)
Are you guys are using operator* for actors anywhere outside of pre-0.19 streams? This 'pipelining operator' was added to make the "auto-magic" stream handshakes work, so I'm wondering whether there are any use cases left after pulling out the streams. Getting rid of this feature would go a long way in reducing complexity in the messaging layer again.

Dominik Lohmann

@dominiklohmann

We're not using it, it was just too inflexible for us.

I'm all for removing it.

Dominik Charousset

@Neverlord

Good to know. Btw, if you can provide me with a minimal example of that response handle thing, I'd take a look.

Dominik Lohmann

@dominiklohmann

While writing a test for reproduction I came across something I am either too stupid to see this Friday evening, or that is broken in CAF: https://gist.github.com/dominiklohmann/694afce863c8ac47739d0dba1943a89c

1 reply

Dominik Charousset

@Neverlord

I'm out of office for a week, but I'll look into that once I'm back. :)

patszt

@patszt

Is there any way to pass \t (TAB) into CLI args?

patszt

@patszt

binary '--option=\"\t\"' seemed to work for CAF 0.17.6

Dominik Charousset

@Neverlord

that should continue to work, since it's done by the shell, isn't it?

patszt

@patszt

The output is different when calling get_or(config).
In 0.18.6 i get string (size = 4, content = "\t")

Dominik Charousset

@Neverlord

Ah, just noticing the extra quotes. As of CAF 0.18, CAF no longer parses arguments for string parameters. So whatever you pass-in is taken as-is.

Where communities thrive

People

Repo info

Activity