GNOME Bugzilla – Bug 660235
Consistent signal handlers to a terminal would be cool
Last modified: 2012-03-26 13:43:17 UTC
It might be just me but I'm a real fan of CTRL-C and CTRL-D on my terminal doing exactly what they do. It'd be awesome if folks-inspect had the exact same behaviour, no? As in, CTRL-D should quit the app, and CTRL-C just move onto the next line.
(mass bump to gnome-3.4 milestone in our new milestone scheme; search this string mass move bug mail)
Created attachment 205222 [details] [review] Fix signal handlers, readline and threading in folks-inspect https://www.gitorious.org/folks/folks/commits/660235-signal-handling That was so very not fun.
This depends on two Vala binding bugs: • https://bugzilla.gnome.org/show_bug.cgi?id=667893 • https://bugzilla.gnome.org/show_bug.cgi?id=667894 It also doesn't behave well if folks-inspect ends up spawning dbus-daemon (e.g. if you're running it as a different user who doesn't already have the daemon running). This is because dbus-daemon ends up in the same process group as folks-inspect, and when you mash Ctrl+C, SIGINT is sent to *both* folks-inspect and dbus-daemon. folks-inspect falls over in a heap when dbus-daemon dies. Talking to halfline on IRC, he came up with the following suggestions, which I haven't implemented due to lack of time at the moment: halflin: pwithnall: you could -isig from your terminal settings pwithnall: *for all users of the program halflin: yea halflin: tcsetattr i mean halflin: or after doing a dbus call you could fork and change the processgroup halflin: or start dbus manually instead of autolaunching it pwithnall: Great, thanks halflin: one last option...disown the tty when you do your first dbus call halflin: then take control of it afterward halflin: actually not sure that will work halflin: okay one more option :-) i mentioned forking change processgroup after doing a dbus call, the other option is fork and dbus call upfront halflin: just setsid() after the fork halflin: and then do a one off dbus call * halflin goes to make a quick coffee pwithnall: I think most of that won't be possible, since the D-Bus stuff is done by a library which the program calls, and both the D-Bus stuff and the readline things run in the same main loop halflin: well you could even if (fork() == 0) { setsid(); system("dbus-send..."); _exit(0) } else wait(NULL) at the top of main.c halflin: or for the other option halflin: just have your program have its guts in a helper halflin: then do one dbus call independent of hte library and spawn out to the helper afterward halflin: or tcsetattr(), just make sure you restore it back afterward
Created attachment 210614 [details] [review] Fix signal handlers, readline and threading in folks-inspect (updated) https://www.gitorious.org/folks/folks/commits/660235-signal-handling-rebase1 Updated to use the actual bindings which landed in bug #667894.
Whoops, the patch should also bump our Vala requirement to 0.15.2. I'll do that before committing.
Comment on attachment 210614 [details] [review] Fix signal handlers, readline and threading in folks-inspect (updated) Committed with a Vala requirement bump to 0.15.2. commit 456575eb920abe5c132d22db0871b5a7fcdde74f Author: Philip Withnall <philip@tecnocode.co.uk> Date: Fri Jan 13 19:37:29 2012 +0000 Bug 660235 — Consistent signal handlers to a terminal would be cool Fix folks-inspect’s handling of SIGINT, SIGTERM and EOF. In the former case, we want to clear the current input buffer and display a new prompt. In the case of SIGTERM we want to exit cleanly, and in the case of EOF we want to exit if the input buffer is empty. The combination of readline, Unix signals and threads in this was unfun. Closes: https://bugzilla.gnome.org/show_bug.cgi?id=660235 NEWS | 1 + tools/inspect/Makefile.am | 1 + tools/inspect/inspect.vala | 30 +++++++++++++++++++++++++++++- 3 files changed, 31 insertions(+), 1 deletions(-) commit 75c7fb1803a27a608d75ffda41306ef9082aa01c Author: Philip Withnall <philip@tecnocode.co.uk> Date: Fri Jan 13 16:29:22 2012 +0000 inspect: Move readline() loop into the GLib main loop The readline() loop is more pain than it’s worth, so we now use readline’s callback interface for command line handling, allowing us to use a single main loop and a single thread for both the aggregator and readline. This should make signal handling a lot easier. Note that this bumps our Vala requirement from 0.15.1 to 0.15.2. configure.ac | 2 +- tools/inspect/inspect.vala | 95 ++++++++++++++++++++++++++++--------------- 2 files changed, 63 insertions(+), 34 deletions(-)
Note that this bug isn't completely fixed yet, due to the problems mentioned in comment #3. It's fixed enough for now, though.
(In reply to comment #7) > Note that this bug isn't completely fixed yet, due to the problems mentioned in > comment #3. It's fixed enough for now, though. smcv: pwithnall: "sorry, if you run folks-inspect not already inside a D-Bus session and you use Ctrl+C expecting a non-fatal signal then you lose" tbh smcv: pwithnall: with a side order of "just what is autolaunch" Good enough for me. FIXED.