FS#67973 - CTRL+C during parallel downloads mixes output and interrupt message

Attached to Project: Pacman
Opened by Eli Schwartz (eschwartz) - Wednesday, 23 September 2020, 04:40 GMT
Last edited by Allan McRae (Allan) - Friday, 27 November 2020, 08:02 GMT
Task Type Bug Report
Category Output
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The sig handler prints out "Interrupt signal received" and exits. This should be the last thing the user sees, and the download display should be preserved in its last state.

Instead, depending on the exact timing, I ended up with output like this:

Interrupt signal received6-1-any 1186.4 KiB 1328 KiB/s 00:06 [-------C o o o o o o o o o o o o o o o o o ] 12%

Or even:

linux-lts-headers-5.4.66-1-x86_64 4.9 MiB 1506 KiB/s 00:07 [------------------C o o o o o o o o o o o o o ] 30%
^Coto-fonts-emoji-20200916-1-any 2.4 MiB 761 KiB/s 00:05 [----------------------c o o o o o o o o o o o o ] 38%
Interrupt signal received4 6.4 MiB 2.17 MiB/s 00:01 [-------------------------------------C o o o o o o o ] 63%
pipewire-0.3.12-1-x86_64 529.6 KiB 865 KiB/s 00:00 [-----------------------------co o o o o o o o o o ] 49%

The cursor is presumably still stuck on lines other than the last line due to its internal accounting while drawing multiple lines for parallelism in the progress meter. Then it simply writes the interrupt message on that line, and quits. We should return the cursor to the bottom before we do anything else.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 27 November 2020, 08:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  git commit db4092e33dacc6a0bb8afd283a82e6f4327cb865
Comment by Anatol Pomozov (anatolik) - Thursday, 22 October 2020, 01:21 GMT
I tried to solve it in 3 different ways and I still see occasional glitches with the SIGINT. That probably come from the fact that "updating cursor_lineno" and "sending ASCII control sequence to console" is not an atomic operation.

Anyway here are 3 different proposed solutions for it:
Comment by Allan McRae (Allan) - Thursday, 22 October 2020, 01:48 GMT
#2 seems a lot of jumping. #3 seems the better version of #1 though I'd rename the function to be consistent with the other console ones.