Re: [PATCH] reading from large or "infinite" source in multio

[Bart Schaefer <schaefer@brasslantern.com>]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

On Thu, Nov 16, 2023 at 5:27 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Why not this?  Any reason that errors from write_loop() should be ignored?

Small addition to that patch:  There's no good reason that the tee/cat
loops should act like interactive shells for purposes of signal
handling etc.

The error checks on the return from write_loop() appear less necessary
once dont_queue_signals() is asserted, but seem prudent anyway.

[-- Attachment #2: procsubs-write_loop.txt --]
[-- Type: text/plain, Size: 800 bytes --]

diff --git a/Src/exec.c b/Src/exec.c
index 97823760f..7d8135266 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -2290,6 +2290,8 @@ closemn(struct multio **mfds, int fd, int type)
 	    return;
 	}
 	/* pid == 0 */
+	opts[INTERACTIVE] = 0;
+	dont_queue_signals();
 	child_unblock();
 	closeallelse(mn);
 	if (mn->rflag) {
@@ -2302,7 +2304,8 @@ closemn(struct multio **mfds, int fd, int type)
 			break;
 		}
 		for (i = 0; i < mn->ct; i++)
-		    write_loop(mn->fds[i], buf, len);
+		    if (write_loop(mn->fds[i], buf, len) < 0)
+			break;
 	    }
 	} else {
 	    /* cat process */
@@ -2314,7 +2317,8 @@ closemn(struct multio **mfds, int fd, int type)
 			else
 			    break;
 		    }
-		    write_loop(mn->pipe, buf, len);
+		    if (write_loop(mn->pipe, buf, len) < 0)
+			break;
 		}
 	}
 	_exit(0);