How to abort getchar in a console application when closing it - c++

I've written a simple command line tool that uses getchar to wait for a termination signal (something like: 'Press enter to stop'). I however also want to handle the SC_CLOSE case (clicking the 'close' button). I did this by using SetConsoleCtrlHandler. But how do I cancel my getchar?
I tried doing fputc('\n', stdin);, but that results in a deadlock.
I can call ExitProcess, but then I get a crash in CThreadLocalObject::GetData when deleting a global CWnd, because the CThreadLocalObject is already deleted (okay, maybe I was lying when claiming it was a simple console application). I guess this might have something to do with the fact that the HandlerRoutine is called from a separate thread (not the main thread).
Maybe there's some sort of getchar with a timeout that I can call instead?

Maybe there's some sort of getchar with a timeout that I can call instead?
You can read console input asynchronously:
#ifdef WIN32
#include <conio.h>
#else
#include <sys/time.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#endif
int main(int argc, char* argv[])
{
while(1)
{
#ifdef WIN32
if (kbhit()){
return getc(stdin);
}else{
Sleep(1000);
printf("I am still waiting for your input...\n");
}
#else
struct timeval tWaitTime;
tWaitTime.tv_sec = 1; //seconds
tWaitTime.tv_usec = 0; //microseconds
fd_set fdInput;
FD_ZERO(&fdInput);
FD_SET(STDIN_FILENO, &fdInput);
int n = (int) STDIN_FILENO + 1;
if (!select(n, &fdInput, NULL, NULL, &tWaitTime))
{
printf("I am still waiting for your input...\n");
}else
{
return getc(stdin);
}
#endif
}
return 0;
}
In such a way, you can introduce bool bExit flag which indicates if your programs is required to terminate. You can read input in specialized thread or wrap this code into the function and call it periodically.

Related

Using sigwait with std::thread and pipe

Consider a parallel program that consists of a number of worker threads. These threads have a poll-loop on some file descriptors. The program is supposed to run until ctrl-c is hit / the process receives a SIGINT. The program should never wake up unnecessarily.
I have devised the following combination of sigwait, std::thread, pipe and pthread_sigmask. Note that in the actual application, there are more file descriptors, hence I am not using atomics for shutting down the threads.
#include <thread>
#include <iostream>
#include <cstdlib>
#include <csignal>
extern "C" {
#include <unistd.h>
#include <fcntl.h>
#include <pthread.h>
#include <poll.h>
}
int fds[2];
void thread_run() {
struct pollfd pfd = {fds[0], POLLIN, 0};
int ret = poll(&pfd, 1, -1);
if (ret != 1) std::terminate();
if (!pfd.revents & POLLIN) std::abort();
}
int main()
{
int ret = pipe(fds);
if (ret) std::abort();
sigset_t ss;
sigemptyset(&ss);
sigaddset(&ss, SIGINT);
ret = pthread_sigmask(SIG_BLOCK, &ss, NULL);
if (ret) std::abort();
std::thread t(thread_run);
int sig;
ret = sigwait(&ss, &sig);
if (ret) std::abort();
char b = 0;
ret = write(fds[1], &b, 1);
if (ret != 1) std::abort();
t.join();
close(fds[0]);
close(fds[1]);
}
The program appears to work without any issues.
Is this approach conforming or am I overlooking any caveats?
Are there any specific error cases that might occur in regular operation
and can be handled more gracefully?
Would the program be still correct if i swap std::thread-creation and pthread_sigmask?
This is a standard recommended approach and it works well. See examples section in pthread_sigmask.
Cannot spot any.
It would not be correct. Most signals are process-specific, which means they get delivered to any thread in the process that does not block that signal. Hence, that signal must be blocked in all threads but the one that handles the signal.
You may like to use std::abort call for unexpected situations. std::terminate is called by the C++ runtime when exception handling fails.

Port program that uses CreateEvent and WaitForMultipleObjects to Linux

I need to port a multiprocess application that uses the Windows API functions SetEvent, CreateEvent and WaitForMultipleObjects to Linux. I have found many threads concerning this issue, but none of them provided a reasonable solution for my problem.
I have an application that forks into three processes and manages thread workerpool of one process via these Events.
I had multiple solutions to this issue. One was to create FIFO special files on Linux using mkfifo on linux and use a select statement to awaken the threads. The Problem is that this solution will operate differently than WaitForMultipleObjects. For Example if 10 threads of the workerpool will wait for the event and I call SetEvent five times, exactly five workerthreads will wake up and do the work, when using the FIFO variant in Linux, it would wake every thread, that i in the select statement and waiting for data to be put in the fifo. The best way to describe this is that the Windows API kind of works like a global Semaphore with a count of one.
I also thought about using pthreads and condition variables to recreate this and share the variables via shared memory (shm_open and mmap), but I run into the same issue here!
What would be a reasonable way to recreate this behaviour on Linux? I found some solutions doing this inside of a single process, but what about doing this with between multiple processes?
Any ideas are appreciated (Note: I do not expect a full implementation, I just need some more ideas to get myself started with this problem).
You could use a semaphore (sem_init), they work on shared memory. There's also named semaphores (sem_open) if you want to initialize them from different processes. If you need to exchange messages with the workers, e.g. to pass the actual tasks to them, then one way to resolve this is to use POSIX message queues. They are named and work inter-process. Here's a short example. Note that only the first worker thread actually initializes the message queue, the others use the attributes of the existing one. Also, it (might) remain(s) persistent until explicitly removed using mq_unlink, which I skipped here for simplicity.
Receiver with worker threads:
// Link with -lrt -pthread
#include <fcntl.h>
#include <mqueue.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void *receiver_thread(void *param) {
struct mq_attr mq_attrs = { 0, 10, 254, 0 };
mqd_t mq = mq_open("/myqueue", O_RDONLY | O_CREAT, 00644, &mq_attrs);
if(mq < 0) {
perror("mq_open");
return NULL;
}
char msg_buf[255];
unsigned prio;
while(1) {
ssize_t msg_len = mq_receive(mq, msg_buf, sizeof(msg_buf), &prio);
if(msg_len < 0) {
perror("mq_receive");
break;
}
msg_buf[msg_len] = 0;
printf("[%lu] Received: %s\n", pthread_self(), msg_buf);
sleep(2);
}
}
int main() {
pthread_t workers[5];
for(int i=0; i<5; i++) {
pthread_create(&workers[i], NULL, &receiver_thread, NULL);
}
getchar();
}
Sender:
#include <fcntl.h>
#include <stdio.h>
#include <mqueue.h>
#include <unistd.h>
int main() {
mqd_t mq = mq_open("/myqueue", O_WRONLY);
if(mq < 0) {
perror("mq_open");
}
char msg_buf[255];
unsigned prio;
for(int i=0; i<255; i++) {
int msg_len = sprintf(msg_buf, "Message #%d", i);
mq_send(mq, msg_buf, msg_len, 0);
sleep(1);
}
}

execl in child process works for only in specific cases

I have been bussy for the last five hours with this problem so I hope someone can help me out. In my C++ program (which I develop in QTcreator on lubuntu) I want to run airodump-ng in the child process of my program. The output of airodump-ng should be directed to the STDOUT of the parent proces. This works with many other programs but strangly enough not with airodump-ng. There is simply no output in the console. This, or my Linux crashes, I get logged out and when I log back in all my programs are closed. Does anybody know why?
#include <QCoreApplication>
#include <unistd.h>
#include <iostream>
#include <stdio.h>
#include <fstream>
#include <sys/wait.h>
using namespace std;
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
//execl("/usr/sbin/airodump-ng", "airodump-ng", (char*)0 );
//dup2(1, 2); //pipe stderr to stdout
pid_t pidAirodump;
pid_t pidAircrack;
int pip[2];
if (pipe(pip) < 0) {
perror("allocating pipe for child input redirect");
return -1;
}
pidAirodump = fork();
if(pidAirodump > 0)//parent
{
pidAircrack = fork();
if(pidAircrack == 0)//pidAircrack
{
close(pip[0]);
dup2(pip[1], 2);
cout << "test" << endl;
//execl("/usr/sbin/arp", "arp", (char*)0 );
execl("/usr/sbin/airodump-ng", "airodump-ng ", "mon0", (char*)0 );
exit(0);
}
}
else//pidAirodump
{
exit(0);
}
wait(NULL);
return a.exec();
}
There's a few oddities in your program. But let's start at the question - you should distinguish between execl not working and the program you're trying to execute is misbehaving. You should not be able to crash linux from a user space program without special privilieges. The code snippet you've posted should not do that (what airpodump-ng does is another question).
If execl fails it will return and set errno, I suggest that you examine that after execl instead of just exiting.
Now for the oddities:
The first fork? Why do you do that? You basically forks and exits the child right away. You fork again and let the parent wait - this should trigger on the fact that the first child has terminated rather immediately.
The pipe, why do you do that if you wan't to keep the standard out? Instead you dup standard err to the write end of the pipe, but you doesn't seem to do anything with the read end.

Listening key events on system level

I need to write an application, which will listen to some key events and after they occurs, application will do something (this isn't important for this question).
The application will run like a deamon - on background (possible on system tray) and waiting for input.
The question is, how can I listen to key events on system level? I prefer some Unix C solution (priority isn't portability to non-Unix system), but if there is some handy Qt class, why don't use it?
EDIT: Isn't there some way, to tell the operating system something like: "Hi! I am here, wake me up on 'some keyboard event'!"?
qxtglobalshortcut is for shortcuts. Qt offers different ways to handle native events. It is for example QWidget::nativeEvent or QAbstractNativeEventFilter.
But if you want to use system API, then you can try my code. It is code which executes inside separate thread and asynchronously invoke method to notify user when event occurs. Ready for copy-paste, but set name of your keyboard.
#include <QApplication>
#include <QDebug>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <dirent.h>
#include <linux/input.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <sys/time.h>
#include <termios.h>
#include <signal.h>
#include <QSystemTrayIcon>
#include <thread>
QSystemTrayIcon *tray;
void handler (int sig)
{
qDebug ("nexiting...(%d)n", sig);
exit (0);
}
void perror_exit (char *error)
{
perror (error);
handler (9);
}
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
tray = new QSystemTrayIcon;
QPixmap px(20,20);
px.fill(Qt::green);
tray->setIcon(QIcon(px));
tray->show();
tray->showMessage("hello","hello",QSystemTrayIcon::Information,1000);
//need this to use invokeMthod
qRegisterMetaType<QSystemTrayIcon::MessageIcon>("QSystemTrayIcon::MessageIcon");
std::thread thread([tray]()
{
struct input_event ev[64];
int fd, rd, value, size = sizeof (struct input_event);
char name[256] = "Unknown";
char *device = NULL;
if ((getuid ()) != 0)
qDebug ("You are not root! This may not work...n");
//my keyboard,set name of yours
device = "/dev/input/by-id/usb-SIGMACHIP_USB_Keyboard-event-kbd";
//Open Device
if ((fd = open (device, O_RDONLY)) == -1)
qDebug ("%s is not a vaild device.n", device);
//Print Device Name
ioctl (fd, EVIOCGNAME (sizeof (name)), name);
qDebug ("Reading From : %s (%s)n", device, name);
while (1){
if ((rd = read (fd, ev, size * 64)) < size)
perror_exit ("read()");
value = ev[0].value;
if (value != ' ' && ev[1].value == 1 && ev[1].type == 1){ // Only read the key press event
qDebug ("Code[%d]n", (ev[1].code));
QMetaObject::invokeMethod(tray,"showMessage",Qt::QueuedConnection,Q_ARG(QString,"Was pressed"),Q_ARG(QString,QString::number(ev[1].code)),
Q_ARG(QSystemTrayIcon::MessageIcon,QSystemTrayIcon::Information),Q_ARG(int,500));
}
}
});
qDebug("after thread");
return a.exec();
}
I used code from here, but just changed it to be in Qt manner.
To run programm you must use sudo.
sudo /path/to/exe
#if you want to run it inside qt creator but with sudo
sudo /path/to/qtcreator
It's not Qt (yet) but is somehow connected, there is this class in the Qxt library called qxtglobalshortcut
Here is the link: http://libqxt.bitbucket.org/doc/tip/qxtglobalshortcut.html
Short: You can't do this.
Longer answer: You can, but you have to write an keyboard-driver.
Even with root/Administrator privileges, you need an input-widget which will have OS input focus. (This is to avoid grabbing the input from other input widgets, like password-fields or your chat). - I fully agree ddriver's comment.
If your service has a focused-widget, you can use Widget's text-events or use QObject::installEventFilter
Another point: You can reuse/notify the event within your service but not send to other applications. See notify. If the service handled the keyboard event, no other application will receive the event. And if focus-widget's application already accepted key-event, your service does not get it.
But I do agree: Some OS allow to access the keyboad-devices. (Like Chernobyl's answer). For these, you can implement an own-Keyboard-device driver / handler. Example for Linux embedded is: QWSServer.
Note for users: Using such driver is not save! Please be carefull if you use 3rd party keyboard-driver! For Windows it is highly recomanded only to use Windows-trusted drivers.
Anyway: Implementing an own keyboard-driver can solve Rainbow Tom's issue.

How to handle a ctrl-break signal in a command line interface

Before I begin, I want to clarify that this is not a command-line tool, but an application that accepts commands through it's own command-line interface.
Edit: I must apologize about my explanation from before, apparently I didn't do a very good job at explaining it. One more time...
I am building a command-line interface application that accepts commands from a user. I have a signal handler setup to catch the signals, which then sets a flag that I need to terminate the application. The problem I'm having is all of the console functions I can find are blocking, which means that I can't detect that I need to exit from my console processing loop until the user presses a key (or enter, depending on the function).
Is there some standard way I can do either non-block console interaction, or is there an elegant way to structure the program so that if I just terminate from the signal thread, that everything will be handled and released properly (please don't mis-understand this, I know how this could be done using locking and releasing the resources from the signaling thread, but this could get messy, so I'd rather avoid it)
Hopefully that explanation makes more sense...
OK - this is working for me on Windows & is portable - notice the #ifdef SIGBREAK - this isn't a standard signal.
#include <csignal>
#include <iostream>
#include <ostream>
#include <string>
using namespace std;
namespace
{
volatile sig_atomic_t quit;
void signal_handler(int sig)
{
signal(sig, signal_handler);
quit = 1;
}
}
int main()
{
signal(SIGINT, signal_handler);
signal(SIGTERM, signal_handler);
#ifdef SIGBREAK
signal(SIGBREAK, signal_handler);
#endif
/* etc */
while (!quit)
{
string s;
cin >> s;
cout << s << endl;
}
cout << "quit = " << quit << endl;
}
On *nix, you can use the signal function to register a signal handler:
#include <signal.h>
void signal_handler(int sig)
{
// Handle the signal
}
int main(void)
{
// Register the signal handler for the SIGINT signal (Ctrl+C)
signal(SIGINT, signal_handler);
...
}
Now, whenever someone hits Ctrl+C, your signal handler will be called.
In Windows: SetConsoleCtrlHandler
On a *nix based system you might not really need a signal handler for this to work. You could specify that you want to ignore the SIGINT call
int main(void)
{
// Register to ignore the SIGINT signal (Ctrl+C)
signal(SIGINT, SIG_IGN);
while(1)
{
retval = my_blocking_io_func();
if(retval == -1 && errno == EINTR)
{
// do whatever you want to do in case of interrupt
}
}
}
The important way that this works is to recognize that non-blocking functions do get interrupted. Normally, you would realize that the blocking function failed (e.g. read()) and reattempt the function. If it was some other value you would take the appropriate error related action.
A better *nix solution that is thread safe is to use pthread_sigmask() instead of signal().
For example, this is how you signore SIGINT, SIGTERM, and SIGPIPE in the current thread and future spawned threads:
sigset_t waitset;
sigemptyset(&waitset);
sigaddset(&waitset, SIGINT);
sigaddset(&waitset, SIGTERM);
sigaddset(&waitset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, &waitset, NULL);