Re: bin/59587: ftp client ascii transfers with progress report fail

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59587; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Luke Mewburn <luke%mewburn.net@localhost>
Cc: source-changes-d%NetBSD.org@localhost,
	gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
	Johnny Billquist <bqt%softjar.se@localhost>
Subject: Re: bin/59587: ftp client ascii transfers with progress report fail
Date: Thu, 15 Jan 2026 23:56:10 +0000

 > Date: Thu, 15 Jan 2026 16:34:48 +1100
 > From: Luke Mewburn <luke%mewburn.net@localhost>
 > 
 > On 26-01-15 04:19, Taylor R Campbell wrote:
 >   | Alternatively: Why not use SA_RESTART, so you don't have to track down
 >   | all the I/O logic that might be interrupted by a signal and arrange to
 >   | run it in a loop?
 > 
 > Even on NetBSD, the previous use of restartable signals (SA_RESTART)
 > caused issues with the implementation of -q QUITTIME.
 > That's why I changed ftp 20210106 to always use interruptable
 > signals for PR 55857 - as confirmed by the submitter.
 
 Sounds like a good reason, thanks!  I hadn't looked at any surrounding
 context, where there is a loop that depends on re-reading the time
 after an alarm expires while waiting in read/recv/accept.