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_at_[hidden]> 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_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals