News for hackers. Stuff that matters.

A comment on FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11. Parent comment

Re:FoundationDB's Flow – Bringing Actor-Based Concurrency to... by mgaunard on Saturday July 04, 2026 @08:56AM (#48785092)
That sounds like a misunderstanding of how the actor model works. An actor doesn't wait. It's an event-driven system, it doesn't get to own and decide when messages get fed to it.
[ Parent | on HN ]
Re:FoundationDB's Flow – Bringing Actor-Based Concurrency to... by d4ng on Saturday July 04, 2026 @12:32PM (#48786663)
Are there any actor system implementations that you know of that work differently?
[ Parent | on HN ]
Re:FoundationDB's Flow – Bringing Actor-Based Concurrency to... by mgaunard on Saturday July 04, 2026 @08:47PM (#48790343)
Well in mine for example, threads are pinned to a core and always spin, and actors are pinned to a given thread (you can have an arbitrary number of actors per thread, they're just objects), so "waiting" is certainly not something you'd use to describe the setup in any capacity.
[ Parent | on HN ]
Re:FoundationDB's Flow – Bringing Actor-Based Concurrency to... by d4ng on Saturday July 04, 2026 @09:40PM (#48790597)
What happens when there are no messages on the queue for a given actor?
[ Parent | on HN ]
Re:FoundationDB's Flow – Bringing Actor-Based Concurrency to... by mgaunard on Sunday July 05, 2026 @05:48AM (#48792747)
An actor does not have a queue; that's again the whole point I already made: it's event-driven, things are decoupled and the actor is not aware of how control flow happens.

Regardless, when the queue which exists and is per-thread is empty, the program terminates.

[ Parent | on HN ]