Date: Thu, 30 Nov 2023 08:15:26 +0100
On Thursday, 30 November 2023 00:17:41 CET Frederick Virchanza Gotham via Std-
Proposals wrote:
> One frequent occurrence that comes to mind is when a terminal on Linux
> running inside a virtual machine is transferring a file over SSH using
> the 'scp' command, and then the network connection drops out . . .
> that freezes the terminal a lot of the time.
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.
If this is what you're alluding to, then it really is "working around poor
code". Just rewrite so that you don't use blocking network writes or you do
enable SO_SNDTIMEO.
I was talking about when the kernel freezes, such as when a kernel thread
oopses.
Proposals wrote:
> One frequent occurrence that comes to mind is when a terminal on Linux
> running inside a virtual machine is transferring a file over SSH using
> the 'scp' command, and then the network connection drops out . . .
> that freezes the terminal a lot of the time.
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.
If this is what you're alluding to, then it really is "working around poor
code". Just rewrite so that you don't use blocking network writes or you do
enable SO_SNDTIMEO.
I was talking about when the kernel freezes, such as when a kernel thread
oopses.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-11-30 07:15:30