Date: Wed, 29 Nov 2023 23:25:07 +0000
On Wed, Nov 29, 2023 at 5:37 PM Julien Villemure-Fréchette wrote:
>
> 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.
In my last job I was writing firmware for security cameras running
embedded Linux. It was a lot more like programming a desktop PC than
programming a microcontroller. When Linux booted up, we had a program
called something like 'supervisor controller', and it had a list of
executable files that it had to run at boot up. It continually
monitored the processes it created, and if one of them died then it
started it back again straight away. If it died a second time, it
would start it again, but after dying a third time it just left it
off. And then there was also a watchdog timer that had to be kicked I
think once a minute, which would reboot the camera.
To make bulletproof software, you can spawn new processes to do the
dirty work . . . . . and that would make sense if your software is
falling over very frequently . . . . but in the case of the program
I'm working on at the moment, a thread rarely freezes. You can run it
for hours and hours and hours, and you might get one or two threads
freeze per day. So it's just not worth going down the road of
separating the program into multiple processes. On a PC with gigabytes
of RAM, I'd have to have many many many threads freeze before I'd have
to worry about accumulating those frozen std::future<bool> objects.
I think I'll just use this one-liner to abandon the value:
::new( &myvar.value() ) std::future<bool>();
>
> 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.
In my last job I was writing firmware for security cameras running
embedded Linux. It was a lot more like programming a desktop PC than
programming a microcontroller. When Linux booted up, we had a program
called something like 'supervisor controller', and it had a list of
executable files that it had to run at boot up. It continually
monitored the processes it created, and if one of them died then it
started it back again straight away. If it died a second time, it
would start it again, but after dying a third time it just left it
off. And then there was also a watchdog timer that had to be kicked I
think once a minute, which would reboot the camera.
To make bulletproof software, you can spawn new processes to do the
dirty work . . . . . and that would make sense if your software is
falling over very frequently . . . . but in the case of the program
I'm working on at the moment, a thread rarely freezes. You can run it
for hours and hours and hours, and you might get one or two threads
freeze per day. So it's just not worth going down the road of
separating the program into multiple processes. On a PC with gigabytes
of RAM, I'd have to have many many many threads freeze before I'd have
to worry about accumulating those frozen std::future<bool> objects.
I think I'll just use this one-liner to abandon the value:
::new( &myvar.value() ) std::future<bool>();
Received on 2023-11-29 23:25:19