>If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind.

You're going to be surprised when you learn that futexes are an abstraction too, ultimately relying on this thing called "cache coherence".

And you'll be really surprised when you learn how cache coherence is implemented.

Emacs 30 has a native graphical port to Android, maybe you can just use that on any Android device.

Well, that's not fundamental. There are plenty of projects that support generating typed bindings for libraries in one language for use by programs in another language. You could do the same thing here.

Fundamentally you go against the grain by generating an IDL from source code. I've never seen this done properly such that it is an improvement over just authoring the IDL in the first place and generating from that.

If your IDL isn't a first-class citizen then what do you expect the derivatives to be?

Is stackfulness required for what the grandparent describes? It seems possible to do this stacklessly: all functions implicitly compile down to a state machine, but futures are never visible.

You need stackful coroutines or continuations (which become really just a kind of growable stack) if you want recursive functions. This is a limitation of Rust’s design.

What do you suggest as an alternative way to express these concepts?

Colloquially, "library" and "service" have 95% of the correct connotations.

Ultimately, it can't. Proprietary software has fundamental limitations that force proprietary software developers to choose technically inferior designs. It's why in the long run proprietary software is doomed.

Do you have better suggestions for what words/phrases to use to refer to these two categories?

I guess service is actually fine. Calling everything a user can run a library is what messed me up. I don't know what a better term might be.

If you predictably do that then the pilots won't speak truthfully in therapy in the first place.

The only way to get the lesser benefit of therapy is to precommit to not report suicidal thoughts.

The greater benefit of "pilots honestly report their suicidal thoughts and then they are stopped from flying" is simply impossible to achieve, and if you foolishly try to get it anyway then you won't even get the lesser benefit.

You're not wrong. But for this to work, the therapists' notes must be forever sealed regardless of circumstance. The first time a pilot darts their plane into a mountainside, and the investigation reveals that they told their therapist about their suicidal thoughts, this precommitment policy will vanish. The therapist will be blamed for 174 deaths. The FAA will apologize for allowing pilots who express ideation to keep flying. Etc.

It's similar to telling your doctor about illicit drug use. Don't do it unless you really trust your doctor to (a) not take adverse implications from the disclosure and (b) not write it down anywhere. Chances of both (a) and (b) are tiny. So, just lie about illegal drugs when asked. Do your own work on making sure to avoid interactions between prescribed drugs and recreational ones.

Welcome to society since, well, forever.

you didn’t think that strong silent man stereotype came from nowhere, did you?

Aren't therapists supposed to make an exception to the doctor/patient confidentiality when the patient is taking about wanting to kill himself and take a plane full of people with him?

> If you predictably do that then the pilots won't speak truthfully in therapy in the first place.

Why do you think anonymous therapy isn't a thing? There has to be a reason, I wonder what it is...

I think you may have misunderstood the problem that this article is solving.

You've implemented something which kills all your child processes when you exit cleanly, but which leaks child processes if you exit uncleanly. This is, frankly, easy to do, and not interesting. It's not a "problem".

The article is solving the problem of: how do I make sure my child processes die even if I exit uncleanly? That's an actual hard problem to solve.

You don't have to subscribe to send a patch to a mailing list.

I have more than once subscribed just to report a bug or send a patch because the mailing list rejects emails from non-subscribers.

Edit: Btw, yes I have done the periodically-check-archive thing in the past, thank you. Hated it. Also missed a response once because I forgot to check and replier didn't CC. I realized like a month later.

It is unfortunate that there are poorly-managed projects with poorly-managed mailing lists (just like there are poorly-managed projects on Github), but sourcehut at least requires a properly-managed mailing list, and I think you should evaluate this workflow on that standard. Tell poorly-managed projects to move to sourcehut, if you want to fix this issue.

Even then, you’re free to opt into daily digests if you’re a subscriber. The message ID allows you to reply to individual messages and threads nonetheless.

Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.

Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.

I know more than one occasion where that has gotten an angry reply.

It's also not the default in many clients. It's tedious and error-prone.