Lots of software needs to deal with potentially unreliable external software: for instance an SSH connection hangs. These kinds of problems already have their solutions, and generally involves monitoring from outside the process itself, like separating a daemon from the client that interacts with it, or forking a new process to run code that will interact with potentially unreliable software so as to isolate the listening/monitoring process from such unpredictability. Then, the crashing subprocess lets your parent subprocess intact and also make it possible to observe possible causes of failure, then decide and take appropriate actions like retrying, etc.

The problem you seek to solve is an architectural one: and its solution is programing language agnostic.

> Some programmers get caught up in fairtytale stuff like the object
model, playing around with "start_lifetimes_as" and forgetting about
how transistors work.

I get that the replies from this mailing list often gets very technical, and common day to day programing task or good coding practices doesn't require involvement into such details. Those often come up as arguments when a proposal would put the consistency of the language at stakes. But most people just want to the the job done fast, and care little about consistency. From my experience, going the fast way without thinking of other solutions that would be more consistent with the model leads to technical debt. This might be acceptable for software you develop, but not for an IS.

Julien

On November 29, 2023 11:07:45 a.m. EST, Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On Wed, Nov 29, 2023 at 3:52 PM Richard Hodges wrote:

If you have spawned 6 threads, and if one of them freezes,...

one would re-write your thread code to include the ability to cancel the thread and exit cleanly, surely?

A well-formed program does not "freeze".


How many rodeos have you been to? Operating systems lock up, device
drivers lock up, virtual machines lock up. 3rd party libraries lock
up. Attend more rodeos.

Let's say you set a socket to non-blocking, and then you make a
non-blocking read on the socket. Of course, if there's no data waiting
there, it should return immediately. But sometimes it doesn't.
Sometimes it hangs forever. Now, you can spend time looking through
the source code for the device drivers you're using (if they're
open-source), and also the operating system you're using (if it's
open-source), and the virtual machine software you're using (by the
way are _any_ of them open-source?), or you can focus on writing your
own piece of software. If you focus on your own piece of software then
you have three options:

Option No. 1) Let it crash, whatever, let the user restart the program
Option No. 2) Gracefully inform the user that something has gone wrong
and that the program will now close and immediately re-open. You can
also tell the user that the unsaved work has been saved to disk.
Option No. 3) Do what I'm doing. . .  keep limping forward while you
can limp . . . . and then when you drop to the ground, keep crawling
forward while you can still crawl, and then when you can't crawl no
more, do a slithery snake movement until you can't move at all, and
then resort to Option No. 2. Most users will have already achieved
their goal before you need to give up entirely.

Some programmers get caught up in fairtytale stuff like the object
model, playing around with "start_lifetimes_as" and forgetting about
how transistors work. I'm gainfully employed writing software with the
aim that we don't get phone calls and emails back saying that
something isn't working . . . and hopefully not putting a few hundred
grand worth of microscopes out of action for week . . . and sometimes
I have to compensate for bugs in other people's work . . . plus my
boss died suddenly back in May so I'm now doing my own work while
trying to reverse-engineer all of his code in order to extend the
feature set in line with product management's aspirations -- that's
why you'll find me doing things like abandoning an std::future<bool>
object.

More rodeos.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals