signals

I have thought a lot and read lot of articles before asking this question here. None of the articles gave me a proper answer. http://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/ QThread* thread = new QThread; Worker* worker = new Worker(); worker->moveToThread(thread); connect(worker, SIGNAL(error(QString)), this, SLOT(errorString(QString))); connect(thread, SIGNAL(started()), worker, SLOT(process())); connect(worker, SIGNAL(finished()), thread, SLOT(quit())); connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater())); connect(thread, SIGNAL

I'm wondering if it's possible to implement preemptive multitasking of native code within a single process in user space on Linux. (That is, externally pause some running native code, save the context, swap in a different context, and resume execution, all orchestrated by user space but using calls that may enter the kernel.) I was thinking this could be done using a signal handler for SIGALRM , and the *context() family but it turns out that the entire *context() family is async-signal-unsafe so that approach isn't guaranteed to work. I did find a gist that implements this idea so apparently

According to APUE 2e Chapter 12.5: If a function is reentrant with respect to multiple threads, we say that it is thread-safe. This doesn't tell us, however, whether the function is reentrant with respect to signal handlers. We say that a function that is safe to be reentered from an asynchronous signal handler is async-signal safe. My questions are Q1: Is there a "general re-entrant" concept (which means re-entrantcy in all circumstances)? If there is, does general re-entrant equal to re-entrant with respect to both multi-thread and async-signal only? Or is there also a third condition that

I am using pthread library under Linux for creating threads and I have two questions about signal handling in such applications. I know that signal handlers are process-wide, which means that if I set handler in process every thread will have this signal handler, also I know that there is pthread_kill function for sending signals to particular threads. I have a question about sending signals using for example shell kill command, as far as I understand, if I type for example kill -INT PID I will send SIGINT to process with this PID , if this is multithreaded program the signal will be delivered

I am working on a node project where I want to write some memory to file when exiting. I figured it was as simple as: process.on('exit', function () { //handle your on exit code console.log("Exiting, have a nice day"); }); However, this code does not execute (on Windows) when CTRL+C is received. Given this is the defacto way to exit Node, this seems a bit of a problem. At this point I tried to handle the signal ( on.('SIGINT',...) ) instead, which results in the error: node.js:218 throw e; // process.nextTick error, or 'error' event on first tick ^ Error: No such module at EventEmitter. (node

If in bash I run a | b | c | d on the command line and then press ^C , which process gets the signal? In short, they all do. When setting up a pipeline, the shell creates a process group . ^C is interpreted by the kernel's line discipline as the user's request to interrupt the process group currently running in the foreground. Sending a signal such as SIGINT to a process group automatically delivers the signal to all processes in the group. Nitz I like experimentation better: #!/bin/bash # FILE /tmp/bla.sh # trap ctrl-c and call ctrl_c() trap ctrl_c INT MY_ID=$1 # Identifier for messages

Using Python 3.4.1 on Windows, I've found that while executing an asyncio event loop , my program can't be interrupted (i.e. by pressing Ctrl+C in the terminal). More to the point, the SIGINT signal is ignored. Conversely, I've determined that SIGINT is handled when not in an event loop. Why is it that SIGINT is ignored when executing an asyncio event loop? The below program should demonstrate the problem - run it in the terminal and try to stop it by pressing Ctrl+C, it should keep running: import asyncio import signal # Never gets called after entering event loop def handler(*args): print(

After using cygwin's ssh to login from windows to linux-hosts, when exiting the remote shell, I always get the annoying msg: "Killed by signal 1" I googled, and realize its harmless, but still annoying... Some suggested you can get rid of the message by using $ ssh -q ... But that has no effect on any of the machines I've tried. Anyone knows a working solution to get rid of this msg? Hongbo Liu Adding following line to your ~/.ssh/config file can squash that message. Update: QUIET must be all CAPS & must added for each host in your config. LogLevel QUIET Added in first line will squash the