Unix sockets

Posted Jan 1, 2025 12:24 UTC (Wed) by khim (subscriber, #9252)
In reply to: Unix sockets by kleptog
Parent article: Systemd improves image features and adds varlink API

> I think you're missing why async/await are so popular

No, I know why they are popular.

> because they're easy to reason about.

No, they are pretty hard to reason about. Much harder then when you work with threads and channels. And they are pretty hard to bugfix.

But on the web they are the only game in the town (because JavaScript is single-threaded language) and on Windows you have to use them because fibers can efficiently support async/await model, but couldn't handle millions of threads.

They are popular because you can add them as another layer of kludges of top of what you already have – and that's precisely my original point that started the whole discussion.

> Because you know exactly where you can be rescheduled, you can minimise locking requirements and easily reason about the parts that do need it.

You only “know the locking requirements” if you are very careful at avoiding sync function. Otherwise they “clog the pipes” and you spend crazy amount of time looking for the root cause. Especially if these sync function not “always slow”, but “sometimes slow”.

> The share-everything that is C(++) threading with rescheduling possible at any point is nearly impossible to reason about by mère humans. Which is why it's not popular (although still common).

It's the exact same model that C# or Java uses. It's hard to say that something that's used by 90% of apps (if not 99%) “is not popular”.

> Btw, async/await is not done using green threads, that would be stupid.

Sure. There are no need to implement async/await with green threads because async/await are already a green threads.

> You could call the tiny fragments of your program that get scheduled "threads" but nobody does that.

Of course. But that's marketing. If you admit that Box<Future<Foo>> (which includes frames for all functions that your function may need to call directly or indirectly) is indistinguishable from Novell Netware style green thread then you wouldn't be understood… even if technically there are very little difference (only in case of Novell Netware it was human who was calculating the size needed for that construct and recursion was allowed, in Rust compiler does the same job and recursion is not allowed… both have pluses and minuses, but essentially they are one and the same… oh, right, await was called something like PostMessage 30 years ago – and you had to use it in preemption points even if you had nothing to “post”).

> This is essential complexity which cannot be removed, only made more ergonomic by language design.

It can be removed, it's not even conceptually hard, but it have to be done at the root. Just make sure there are no sync functions. Like in one well-know OS.

But of course that wouldn't be done. We like our pile of kludges way too much to do something about it.

> I think this patch set is being sold wrong.

I don't think it's “sold” anymore. Google wanted to reduce difference between their kernel and mainstream one. After looking on the reaction… I think at this point they just decided to carry that patch instead of upstreaming it.

> So you'd have maybe 2 threads per CPU with only one running at a time.

That would be an interesting project, but that would be entirely different project. Google Fibers design was the solution for the two-colors problem. And with kernel threads used as basis you no longer have it. You don't need special mutexes (like Tokio mutex, your Fiber-aware code can include communications with regular threads, etc.

That was the goal. And it's achieved, that's how Google Fibers were used for more than a decade (and would probably be used for the foreseeable future).

Every single reviewer tried to bend that patchset into Erlang-style model or M:N model… which made it entirely uninteresting for Google: sure, someone else may benefit from all that… but Google would still need to carry patch for Google Fibers… what's the point of pushing it, then?