I disagree that async/await is purely about avoiding overhead of kernel threads. Kernel threads are actually not that expensive these days. You can have a server with 10,000 threads, no problem.

The problem is synchronization becomes extremely hard to reason about. With event loop concurrency, each continuation (callback) becomes effectively a transaction, in which you don't need to worry about anything else modifying your state out from under you. That legitimately makes a lot of things easier.

The Cloudflare Workers runtime actually does both: There's a separate thread for each connection, but within each thread there's an event loop to handle all the concurrent stuff relating to that one connection. This works well because connections rarely need to interact with each other's state, but they need to mess with their own state constantly.

(Actually we have now gone further and stacked a custom green-threading implementation on top of this, but that's really a separate story and only a small incremental optimization.)

▲

catern 4 days ago | parent | next [-]

I totally agree with your framing of the value of async/await, but could you elaborate more on why you think that this behavior (which I would call "cooperative concurrency") is important for (ocap?) RPC systems? It seems to me that preemptive concurrency also suffices to make RPC viable. Unless you just feel that preemptive concurrency is too hard, and therefore not workable for RPC systems?

▲

kentonv 3 days ago | parent [-]

Almost all ocap systems seem to use event loops -- and many of the biggest ocap nerds I know are also the biggest event loop nerds I know. I'm not actually sure if this is a coincidence or if there's something inherent that makes it necessary to pair them.

But one thing I can't figure out: What would be the syntax for promise pipelining, if you aren't using promises to start with?

	▲	catern 3 days ago \| parent [-]
		>What would be the syntax for promise pipelining, if you aren't using promises to start with? Oh, great point! That does seem really hard, maybe even intractable. That's definitely a reason to like cooperative concurrency, huh... Just to tangent even further, but some ideas: - Do it the ugly way: add an artificial layer of promises in an otherwise pre-emptive, direct-style language. That's just, unfortunately, quite ugly... - Use a lazy language. Then everything's a promise! Some Haskell optimizations feel kind of like promise pipelining. But I don't really like laziness... - Use iterator APIs; that's a slightly less artificial way to add layers of promises on top of things, but still weird... - Punt to the language: build an RPC protocol into the language, and promise pipelining as a guaranteed optimization. Pretty inflexible, and E already tried this... - Something with choreographic programming and modal-types-for-mobile-code? Such languages explicitly track the "location" of values, and that might be the most natural way to represent ocap promises: a promise is a remote value at some specific location. Unfortunately these languages are all still research projects...

▲

frollogaston 4 days ago | parent | prev [-]

It's true that JS await is kinda like releasing a lock, but otherwise, you'd just use a mutex whenever you access shared state. Which is rare as you said, and also easy to enforce in various langs nowadays.

▲

kentonv 4 days ago | parent [-]

I said that shared state between connections is rare, but shared state within a connection is extremely common. And there are still multiple concurrent things going on within that connection context, requiring some concurrency mechanism. Locking mutexes everywhere sounds like a nightmare to me.

▲

frollogaston 4 days ago | parent [-]

Ah I see. Well that is typically just fan-out-fan-in like "run these 4 SQL queries and RPCs in parallel and collect responses," nothing too complicated since the shared resources like the DB handle are usually thread-safe. It works out fine in Go and Java, even though I have unrelated reasons to avoid Go.

▲

branko_d 3 days ago | parent | next [-]

“Running 4 SQL queries in parallel” is not thread-safe if done in separate transactions, and on data that is not read-only.

If some other transaction commits at just the wrong time, it could change the result of some of these queries but not all. The results would not be consistent with each other.

▲

frollogaston 3 days ago | parent [-]

Thread-safe just means that the threading by itself doesn't break anything. The race condition you're describing is outside this scope and would happen the same in a single-threaded event loop.

Btw if you really want consistent multi reads, some DBMSes support setting a read timestamp, but the common ones don't.

▲

branko_d 3 days ago | parent [-]

> would happen the same in a single-threaded event loop

Well...if you implemented a relational DBMS server without using threads. To my knowledge, no such DBMS exists, so the distinction seems rather academic.

> Btw if you really want consistent multi reads, some DBMSes support setting a read timestamp, but the common ones don't.

Could you elaborate? I can't say I heard of that mechanism. Perhaps you are referring to something like Oracle flashback queries or SQL Server temporal tables?

Normally, I'd use MVCC-based "snapshot" transaction isolation for consistency between multiple queries, though they would need to be executed serially.

	▲	frollogaston 2 days ago \| parent [-]
		I was talking about the client side here, which is maybe a web backend. If it's using threads, at least the connection pool will be thread-safe. If it's event loop, N/A. If you want to look at the DBMS itself, well typically there's a separate process per connection, but say it uses threading instead... It'd be thread-safe too. You aren't hitting UB by doing concurrent xacts. Snapshot xact is what I was thinking about. Not sure about Oracle, but in Spanner they can be parallel.

▲

kentonv 4 days ago | parent | prev [-]

The Cloudflare Workers runtime is 1000x more complicated than your average web application. :)