On Wed, 29 Nov 2023 at 17:37, Julien Villemure-Fréchette via Std-Proposals <
std-proposals_at_[hidden]> 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.
>
> The problem you seek to solve is an architectural one: and its solution is
> programing language agnostic.
>

Right, you can't fix it by adding a member function to std::optional.
That's just silly.



>
> > 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
>