https://pantsbuild.org/ logo
Join Slack
Powered by
I have a draft PR for detecting if the user hit Ct...
# development
h
I have a draft PR for detecting if the user hit Ctrl-C in --v2-ui mode: https://github.com/pantsbuild/pants/pull/9043 . I'm not sure what the best way to actually exit pants is once we've detected that the keystroke happened
ideally we'd raise SIGINT just like what normally happens when a terminal program gets Ctrl-C - but I realize, I'm not actually sure how that normally happens
i.e. is that the shell sending SIGINT to its child process, or the child process sending SIGINT to itself?
a
the shell converts a ctrl-c into a SIGINT
to handle ctrl-c, you handle SIGINT
h
I also tried doing this other thing involving the rust bindings to termios and the ISIG flag, but it didn't work either: https://github.com/pantsbuild/pants/pull/9045
a
there’s some prior art for eventually making pants die with backoff and retry i think in nailgun_protocol.py or nailgun_client.py
h
@aloof-angle-91616 in terminal raw mode the shell doesn't send SIGINT, which is why Ctrl-C doesn't doing anything right now if the --v2-ui flag is passed, that's what I'm trying to fix
a
the use case there is to convert a SIGINT to the thin pants runner into an appropriate signal to send to pantsd
what is terminal raw mode? i’ll google
h
I think in practice "raw mode" is basically setting a bunch of individually-configurable terminal flags using the API termios exposes, but I don't understand the intricacies of unix terminal emulators super well
but it's what you need to set in order to have fine-grained control over exactly where a program displays characters in a terminal, which we need for --v2-ui
a
kris wilson i recall wrote the original tty manipulation necessary for pantsd and he experienced difficulty there too. it’s an arcane art for now
and ok — does termios give you a way to listen for ctrl-c then?
h
that's what I thought the ISIG flag did, based on 
man termios
a
oh!
h
Copy code
ISIG   When  any  of  the characters INTR, QUIT, SUSP, or DSUSP are re‐
              ceived, generate the corresponding signal.
but maybe I'm misunderstanding this, maybe I'm not using the rust termios bindings correctly, maybe something else is going on
a
signal handling is hard for this exact reason i think
sometimes when i’m stuck i will clone the rust project i’m depending on, set cargo to use that, and just add print statements in the source
h
@average-vr-56795 @red-balloon-89377 pinging the UK crowd just to see if you guys had any ideas about this
r
Replied: https://github.com/pantsbuild/pants/pull/9043#discussion_r373420305 The TL;DR is that according to other projects using termion, this is the right way to detect them. On how to exit once we detected the event, I need to look a bit more.
The best way I can think of is to create an enum 
RenderResult
, with values 
{Ok(()), Err(String), Ok(Signal)}
or something like that, and return that from 
render
. Then, we can propagate that up to the 
Scheduler::run
method’s current loop, and use the mechanism it already has to handle exits (https://github.com/blorente/pants/blob/998e4edbe31c64aeacac5142ad90433fce9a748b/src/rust/engine/src/scheduler.rs#L367)
h
@red-balloon-89377 I think your suggestion will solve the problem at hand, of quitting cleanly when the user hits Ctrl-C
the only problem is, we're no longer doing that by the specific mechanism of sending SIGINT, we're just detecting that keystroke and deciding to run some custom code when we see it
maybe that's not a problem - Ctrl-C is probably the only standard unix keyboard command that people use very often
but, for instance, Ctrl-Z sends a (different) signal to aprocess
to make it go to the background
and I think there's a few other keyboard commands that should send some kind of signal
and it seems odd to be that, in a terminal raw mode application, we'd have to handle all of those with specific logic that doesn't involve signals
(I mean, we don't have to, probably no one will complain if Ctrl-Z just doesn't work, but it makes me suspicious that we're solving the problem in the wrong way here)
r
I feel like that's a trade-off one makes when buying into raw mode though. An alternative would be to still detect the keystrokes, but exit raw mode and manually send the signals back to the terminal, but honestly that sounds a bit more convoluted and black magic
Open in Slack
PreviousNext
Powered by