From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 6178 invoked from network); 7 Mar 2022 21:26:27 -0000
Received: from 4ess.inri.net (216.126.196.42)
  by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2022 21:26:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received: from mail-pj1-f52.google.com ([209.85.216.52]) by 4ess; Mon Mar  7 16:19:16 -0500 2022
Received: by mail-pj1-f52.google.com with SMTP id m11-20020a17090a7f8b00b001beef6143a8so404376pjl.4
        for <9front@9front.org>; Mon, 07 Mar 2022 13:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=mforney.org; s=google;
        h=date:to:subject:from:message-id:user-agent;
        bh=Uq8eJ4/0FEvRKR0faM0DCtqbE1nur5UPRTOmA7xFt8Q=;
        b=2Y33hh0upNICXFIQJFzjfj65xIyDDgSYE0nB+HvRO13CsLaEYXmqcUr98fdSmXHGE1
         20ZEiOJJQfpoQxzZpnVy7fX5oINW9DTfCf3hdOIf+iZowbqUI3xIvlZmOwCiCZYHksbu
         +LmoekCZUkGz02iECkCClDpVook2O4wswmsB9zBI2ZWd5IBUWv99KcyExwyFJaQ1FJ4X
         5hh24717pos982eTIWTMA4JhNLeeZk30pk+kHQuixsCLS6b9dGzXzWzZidSa5SkgvgGo
         XwbKkY+tsYep1XrSSUTbuzgLn3W5CGrP+/v1Tx76lWCL++DqJkmW+03Kbg5DyjllircK
         YKug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:date:to:subject:from:message-id:user-agent;
        bh=Uq8eJ4/0FEvRKR0faM0DCtqbE1nur5UPRTOmA7xFt8Q=;
        b=1W9P+6FdCvaMImZ/AXxQzpDh/mHzHU8aP1zNGz1njdpBjJSR0KWDr0ulpf4x76EA+7
         Szra733n9BWvC+9YfnzE0O6loAfy9Oeal6XJvpZGnLc/mTk1Vwp3U4cLjgKGgi4h9wdL
         mOUMAvy/zvD7KMaHHk/riZMPHa1mTZ7ZzQmWmGCGMJF5ihg5JVYbHtLJ0R3k+Tdu/Duu
         pqkc/+MTywKxNdMEmqFIHtoLAwC7zunXkMqXKjWl96A7zV4sLphGU3SE9P59vioBiRQ1
         jjh/XXmpYtQ5KVibAL1FXeEhCVLcAcw2wshNmTtjwKAqF31eJx8PL8jjbPwB28fuseBR
         USdw==
X-Gm-Message-State: AOAM531iAgrsBtIbtLGk5RCv7te65pDYg9HzNdRBxLsgIOwC9Rb/wCSm
	tWtVrrH9UfVoZ7FPsFYCHPyTu0YZHo/0FLskXmo=
X-Google-Smtp-Source: ABdhPJx5weMv7b4SZlZucD70cWNvJpjbR3jdIbOv0WytBl5/14tJlJdsqxKHrdStRJ03DXof70cWGw==
X-Received: by 2002:a17:902:c947:b0:151:a988:f3de with SMTP id i7-20020a170902c94700b00151a988f3demr14038068pla.104.1646687948745;
        Mon, 07 Mar 2022 13:19:08 -0800 (PST)
Return-Path: <mforney@mforney.org>
Received: from localhost ([98.45.152.168])
        by smtp.gmail.com with ESMTPSA id ls7-20020a17090b350700b001bd37f4e045sm264088pjb.26.2022.03.07.13.19.07
        for <9front@9front.org>
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Mon, 07 Mar 2022 13:19:08 -0800 (PST)
Date: Mon, 07 Mar 2022 13:19:06 -0800
To: 9front@9front.org
From: Michael Forney <mforney@mforney.org>
Message-Id: <2Z2GAIQLXW88G.24294JTWIM6TD@mforney.org>
User-Agent: mblaze/1.2
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: ISO-certified extension GPU-based standard cache 
Subject: [9front] rc interrupt regression
Reply-To: 9front@9front.org
Precedence: bulk

For a little while, I've noticed unexpected behavior with rc in rio
involving interrupts.

The issue can be reproduced fairly easily by cating a file with
enough lines to fill the window, then pressing del just enough times
so that the rc prompt is written. The next command you run is
dropped, with no indication in $status that it didn't succeed.

When rc is blocked on writing its prompt, the del press causes rio
to first scroll to the end of the window and then start a new proc
to send the interrupt. Scrolling the window unblocks the write of
the prompt, which succeeds. The interrupt then arrives, setting the
interrupt trap in rc.

At this point, rc has written the prompt, has a pending interrupt,
and now is waiting on the next line of input. If we type a command
such as `echo hello`, the command is parsed successfully, and then
pushed onto the runq.  Xrdcmds returns, then dotrap() finally detects
the interrupt and the command is dropped, without setting $status.

This behavior was introduced in commit
189731aad01e09db1807c78af421c615ed3a3242 rc: make it portable (for UNIX)

Specifically, the following hunk:

@@ -995,7 +1032,6 @@ Xrdcmds(void)
 			p->lex = 0;
 		} else
 			--p->pc;	/* re-execute Xrdcmds after codebuf runs */
-		ntrap = 0;	/* avoid double-interrupts during blocked writes */
 		start(codebuf, 2, p->local, p->redir);
 	}
 	lex = 0;

Adding back this line fixes the issue for me. Was this a deliberate
change needed for the unix port? If so, is there some other way to
solve this problem?