On 30/11/2023 10:23, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Thu, Nov 30, 2023 at 7:15 AM Thiago Macieira wrote:
>>
>> That is not a freeze, AT ALL. The scp process is simply waiting on the ability
>> to send more. I don't know if it has timeouts by default, but that's a
>> limitation of scp instead of TCP or the OS. It should react to Ctrl+C and be
>> killable anyway. And the terminal application is not stuck.
>
>
> It doesn't react to Ctrl+C. This isn't all about the one use case I
> put forward of threads freezing. In embedded systems you could have an
> object managing an RS232 connection or a bus, and it gets screwed up
> and you want to discard it without going through the normal shutdown
> procedure.

How can I put this diplomatically? Your attitude here is just /wrong/.
Completely and utterly /wrong/. Nothing you have said would be
acceptable as "best practice" in embedded development.

To be fair, not all embedded development is done as "best practice".
And sometimes even when developers know better, there are other
pressures - time, money and management - forcing shortcuts and hacks to
be taken.

But no, you never "discard" or "drop" a bus. If you have something you
want to shut down, and the "normal" shutdown procedure can't work, you
support an "abnormal" shutdown procedure.

If you have an object whose lifetime ends, and you want to avoid running
the destructor, then your architecture is borked. Your design is
broken. It is not the network connection that has failed, it is the
software designer that has failed.

Maybe the TCP/IP connection has had trouble, and you can't wait for the
various retries and timeouts for a proper close before starting again.
Fair enough - but you don't just scrub out some bits of the connection
and hope for the best! You handle it properly - you move the connection
to a side object that will deal with the timeouts and closure, while you
open your new connection.

Maybe that's hard to do. Maybe it's hard to test. Maybe you need a
proxy class between your std::optional<> and the original T, with a
destructor to handle the situation. But that's your job. Stop shirking
your responsibilities. Stop claiming everyone else writes buggy code,
so you want the C++ standard to make it easier for /you/ to write buggy
code. Stop tarring a whole industry as incompetent just because /you/
refuse to do a good job. And, in general, stop making claims about
"embedded developers" or "in the real world". You don't speak for
embedded developers, and you don't speak for "the real world". As an
embedded developer who wants good, clean, working code, your attitude
represents the worst we see. I don't want the C++ standards to change
here - I want your attitude to change!