Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

apple.github.io

Post reply on HN
Print view View original

11–20 of 38 posts

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#11

Post by whizzter »

alfiedotwtf wrote: post #9
hiyfsch wrote: post #5

Earlier quoted context omitted.

Just because coroutines exist doesn’t mean everything should use them for concurrency. Why would it be better? It’s pretty easy to set up threads in general.

The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).

The main benefit is not having the cost of threads, f.ex. a default thread on Windows has something like 500k of stack iirc, scale that to 10000 concurrent requests and you're looking at 5gb of memory _just for stacks_, compared to a couroutine,etc that has perhaps a few kb's of usage (even if in deep stack-traces).

This is why we have stuff like io_uring these days, the bottleneck moved to the kernel calls (especially with Spectre style attacks) when concurrent costs in the applications went down.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#12

Post by menaerus »

whizzter wrote: post #11
alfiedotwtf wrote: post #9

Earlier quoted context omitted.

The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls). The main benefit is not having the cost of threads, f.ex. a default thread on Windo…

> Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).

In cooperative scheduling how is it possible to have two coroutines running concurrently?

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#13

Post by ddorian43 »

whizzter wrote: post #11
alfiedotwtf wrote: post #9

Earlier quoted context omitted.

The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls). The main benefit is not having the cost of threads, f.ex. a default thread on Windo…

> aren't reliable if an async/coroutines moves threads between calls

Then just don't move them between threads and you're good with thread locals, no?

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#14

Post by RossBencina »

pjmlp wrote: post #3

This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20. Also how is the supposed Swift rewrite going on?

Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#15

Post by d4ng »

RossBencina wrote: post #14
pjmlp wrote: post #3

This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20. Also how is the supposed Swift rewrite going on?

Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.

What are actors doing between finishing processing the last message and receiving the next one?

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#17

Post by mgaunard »

pjmlp wrote: post #3

This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20. Also how is the supposed Swift rewrite going on?

Coroutines aren't great, even C++26 is explicitly avoiding them for its foundational concurrency model.

In any case a good concurrency library doesn't need more than C++14.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#18

Post by mgaunard »

d4ng wrote: post #15
RossBencina wrote: post #14

Earlier quoted context omitted.

Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.

What are actors doing between finishing processing the last message and receiving the next one?

yield to the event loop

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#20

Post by fidotron »

khurs wrote: post #16

Why has FoundationDB not been professionalised? Better website, better docs, official GUI? Is Apple responsible for preventing its wider uptake? Or alternative databases stronger?

Because it converts all normal DBA tasks into development tasks. If this fits your org (and at huge scale it is more likely) then that's fine, but for small/mid/growth places that can be a PITA.

There does seem to be more effort going into an SQL layer, but it's very hard to know what the state of layer dev and direction is these days, especially if you're not located near core devs.

Post reply on HN