wt., 28 lis 2023 o 17:13 Brian Bi via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Tue, Nov 28, 2023 at 10:27 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, Nov 28, 2023 at 3:22 PM Breno Guimarães wrote:
>> >
>> > When I spawn a thread and it freeze, I usually just debug my code.
>>
>>
>> Debug writing into a TCP socket across the internet, with the TCP
>> segments arriving at the far computer and being sent out an RS232
>> port, waiting for a reply and sending it back into the TCP socket.
>>
>> Before engaging in this debugging exercise, perhaps make a finite list
>> of all the things that can go wrong. You'll need a few reams of paper.
>
>
> If the thread on the local computer freezes, you can't blame the other end of the TCP connection for it. Sure, it might never receive a response from the other end... but you can set timeouts for those operations to prevent the thread from blocking, use `select` or one of its variants, use asynchronous I/O, or interrupt the I/O operations by sending a signal. There are a lot of options other than leaking threads. This is the first time I've ever heard of someone other than a novice acting as if not leaking threads is some kind of hardship for them.
>

I once met a production system where the fix for memory leak was
restarting the whole program instead of fixing the underlying problem.
This is a great example of the XY problem, instead of fixing the core
problem ("not freeze thread pernamelty")
we find a replacement "solution" ("break type system to leak resources" sic!).


>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Brian Bi
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals