9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] rc interrupt regression
@ 2022-03-07 21:19 Michael Forney
  2022-03-18 23:33 ` [9front] " Michael Forney
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Forney @ 2022-03-07 21:19 UTC (permalink / raw)
  To: 9front

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?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [9front] Re: rc interrupt regression
  2022-03-07 21:19 [9front] rc interrupt regression Michael Forney
@ 2022-03-18 23:33 ` Michael Forney
  2022-03-21 18:08   ` cinap_lenrek
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Forney @ 2022-03-18 23:33 UTC (permalink / raw)
  To: 9front

On 2022-03-07, Michael Forney <mforney@mforney.org> wrote:
> 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?

Ping. Any thoughts on this? Has anyone else noticed it?

I've reverted that hunk in my local tree since it kept tripping me up
(did my cp command succeed, or did rc eat it?).

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [9front] Re: rc interrupt regression
  2022-03-18 23:33 ` [9front] " Michael Forney
@ 2022-03-21 18:08   ` cinap_lenrek
  0 siblings, 0 replies; 3+ messages in thread
From: cinap_lenrek @ 2022-03-21 18:08 UTC (permalink / raw)
  To: 9front

yeah, i dont know of a good way to fix it. the ntrap=0 is fine for
plan9, but breaks the unix signal handling as trap[x] and ntrap
get out of sync.

so if you find a solution fixing both that would be great.

--
cinap

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-03-21 18:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-07 21:19 [9front] rc interrupt regression Michael Forney
2022-03-18 23:33 ` [9front] " Michael Forney
2022-03-21 18:08   ` cinap_lenrek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).