can anyone pleaase guide to run hello worlld program steps..... i have compiled camke completely...
Hi I have created an example to study the difference between request.then and request.await. I have a scoped actor which sends 5 messages to a master actor and this master actor in its behavior sends a message to a slave actor which returns the sum of 2 integer and sleeps for 1 seconds.
It is as expected i.e. if I use then I see that masters behaviors are activated without waiting for slave answers
the question is when I use <message_priority::high> await does not function after the first call
is this expected?
Regarding the high-prio: you shouldn't need to forward it with hight priority. Mind making a minimal example and open a GitHub issue?
OpenMP: be careful when combining CAF with any other framework that spins up a thread pool on its own. If both are busy, you pay for a lot of context switches by overbooking the CPU.
OpenMP: be careful when combining CAF with any other framework that spins up a thread pool on its own. If both are busy, you pay for a lot of context switches by overbooking the CPU.
Incomplete type usually means you're only having a forward declaration, i.e., you're missing the include. An example for publish/remote_actor is here: https://github.com/actor-framework/actor-framework/blob/master/examples/remoting/distributed_calculator.cpp.
That's not how you use request. :)
You're not telling it what to do with the response and you can't take an event-based actor as value. Have a look at the example: https://github.com/actor-framework/actor-framework/blob/master/examples/message_passing/request.cpp.
You're not telling it what to do with the response and you can't take an event-based actor as value. Have a look at the example: https://github.com/actor-framework/actor-framework/blob/master/examples/message_passing/request.cpp.
Then that's just
sender->send(receiver, ...), isn't it? Generally speaking, though, CAF does not hand out pointers because actors are supposed to share no state. You handles instead. Maybe this here helps you grok how CAF is structured: https://www.cafcademy.com/articles/implementing-actors-part-1
@Neverlord Hello Dominik. We experiencing some strange caf behavior. Our CAF version is 0.17.4. We have library that has event_based_actors. Library has some method with return values, so is blocking by nature. To work with this actors we use this pseudo code
caf::scoped_actor self{system_};
int result = -1;
self
->request()
.receive(
[&](...) {
...
},
[&](caf::error& err) {
...;
});
return result;With this code we experiencing timeout before our application with loaded library exits about 30 seconds.
We can reproduce that still one line:
caf::scoped_actor self{system_};can produce that behavior.
Two log file with and without that line are above.
Can you share your thoughts on this. What maybe the cause?
Hm. If you can reproduce some kind of hanging even with just calling the constructor of
scoped_actor, then I don't see what might cause this in CAF itself. The constructor has no blocking code in it: https://github.com/actor-framework/actor-framework/blob/master/libcaf_core/src/scoped_actor.cpp#L41. Unless it has something to do with other factors in your application, the only thing that might block is the logger if it gets overwhelmed with log messages because it's using a fixed-size buffer (precisely to slow down an application if logs too fast for the logger to keep up). But for you to wait several seconds in this call, you would have produce tons and tons of log messages in another thread.
in distributed_calculator.cpp a stateful actor is used for this purpose
I get something like invalid use of 'void'
I don't know where the void comes from actually
It's generally more helpful to paste the error into chat using markdown blocks. :)
Hard to tell without the full context what's wrong here. The
Hard to tell without the full context what's wrong here. The
self->request(...).receive(...) part LGTM tho: https://github.com/actor-framework/actor-framework/blob/master/examples/message_passing/request.cpp#L65.
thank you :D