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.