I need to understand what happens to a process in Unix when it calls the pause() function.
Considering a simple state diagram with three states: ready, run and wait. If my programm only prints its pid and than makes pause, will the program be indefinitely in "wait" state?
If it does while(1) { pause() }, it will be indefinitely in "wait" state too?
From the manpage:
pause() causes the calling process (or thread) to sleep until a signal is delivered that either terminates the process or causes the invocation of a signal-catching function.
So the program may not be indefinitely in sleep state ("wait", to use your word). It will leave that state if a signal is received. However, if you enclose the pause() call in a tight infinite loop as per your example, the program will run again when a signal is received but promptly go back to sleep.
When signals are received during pause(), the signal handler (if any) will run, and control will return to the point right after the pause() syscall as soon as the handler returns.
Related
When exactly signal will start execution in unix ?Does the signal will be processed when system turns into kernel mode? or immediately when it is receives signal? I assume it will be processed immediate when it receives.
A signal is the Unix mechanism for allowing a user space process to receive asynchronous notifications. As such, signals are always "delivered by" the kernel. And hence, it is impossible for a signal to be delivered without a transition into kernel mode. Therefore it doesn't make sense to talk of a process "receiving" a signal (or sending one) without the involvement of the kernel.
Signals can be generated in different ways.
They can be generated by a device driver within the kernel (for example, tty driver in response to the interrupt, kill, or stop keys or in response to input or output by a backgrounded process).
They can be generated by the kernel in response to an emergent out-of-memory condition.
They can be generated by a processor exception in response to something the process itself does during its execution (illegal instruction, divide by zero, reference an illegal address).
They can be generated directly by another process (or by the receiving process itself) via kill(2).
SIGPIPE can be generated as a result of writing to a pipe that has no reader.
But in every case, the signal is delivered to the receiving process by the kernel and hence through a kernel-mode transition.
The kernel might need to force that transition -- pre-empt the receiving process -- in order to deliver the signal (for example, in the case of a CPU-bound process running on processor A being sent a signal by a different process running on processor B).
In some cases, the signal may be handled for the process by the kernel itself (for example, with SIGKILL -- or several others when no signal handler is configured).
Actually invoking a process' signal handler is done by manipulating the process' user space stack so that the signal handler is invoked on return from kernel-mode and then, if/when the signal handler procedure returns, the originally executing code can be resumed.
As to when it is processed, that is subject to a number of different factors.
There are operating system (i.e. kernel) operations that are never interrupted by signals (these are generally relatively short duration operations), in which case the signal will be processed after their completion.
The process may have temporarily blocked signal delivery, in which case the signal will be "pending" until it is unblocked.
The process could be swapped out or non-runnable for any of a number of reasons -- in which case, its signal handler cannot be invoked until the process is runnable again.
Resuming the process in order to deliver the signal might be delayed by interrupts and higher priority tasks.
A signal will be immediately detected by the process which receives it.
Depending on the signal type, the process might treat it with the default handler, might ignore it or might execute a custom handler. It depends a lot on what the process is and what signal it receives. The exception is the kill signal (9) which is treated by the kernel and terminates the execution of the process which was supposed to receive it.
I've set up a signal handler in my main thread. A separate thread then sends my main thread this signal. My signal handler is being called appropriately, but I'm not sure what the 'State' of the main thread is at this point, and whether it can be recovered. basically, my main thread was blocked on a read() call, and a different thread has sent it a signal due to an extraordinary event. I thus want the read() call to fail (EINTR?), hence my other thread sending the main thread this signal.
It depends on how you installed the signal handler. If the signal handler was installed using sigaction() and without specifying the SA_RESTART flag, then the read() will fail with EINTR if it has not transferred any data yet.
In general, the thread that has handled a signal can continue normally after the signal handler returns. That's really the whole point.
Remember though, that the signal might have arrived just after the read() had successfully returned, too - or worse, just before you called read() (in which case the read() will still block).
My understanding is A waiting process is a situation in which process is waiting for the completion of some event before resuming activity. A program or process in a wait state is inactive for the duration of the wait state.
Basically in the above the waiting on some event to occur.
what about sleeping?
Sleep causes the process to give up the remaining of its time slice and stay in non-runnable state for the given duration Vs Wait: pauses execution until an event completes.
A process, as you rightly said- waits on an event. A sleep is a time driven wait.
Please check this on Wikipedia: http://en.wikipedia.org/wiki/Process_state .
Ready or waiting, it's more CPU resource linked:
A "ready" or "waiting" process has been loaded into main memory and is awaiting execution on a CPU
Sleeping, see also In *nix, what causes "sleeping" in top command?, it's more functional designing:
It's waiting for data, interaction with other processes, like an Apache server that waits for a user query, it's a more normal process state...
"wait" : if you executed command shell will wait(hold) and does not execute any more command until the command is finished successfully and switches to next.
"sleep" : if the command you run is sleep 10, then it spend 10 seconds not outputting anything. So the shell spends 10 seconds in an internal wait on the sleep process.
sleep:
This command is issued to suspend execution of the system for the specified time limit mentioned in it as parameter.
For instance
sleep 50
The above suspend the execution of the shell in UNIX operating system for 50 seconds specified.
wait:
wait causes waiting of the process specified in parameter or the job specified in parameter to wait. If nothing is specified all jobs in pipeline are put to waiting state that is all current child process which are currently active are put to wait status. Wait also return the return status. If a child has already exited by the time of the call (a so-called "zombie" process), the function returns immediately. Any system resources used by the child are freed. The return status is generally the exit status of last job in the pipeline process which was put to waiting state. In case of scenario in which no job or process is specified the return status would be zero.
The general syntax of wait command in UNIX operating system is
wait n
where n is optional which denote the process or job
In Unix
Waiting: is the fact that a process is waiting for some external event like the reception of data from the network, reading bytes from disk etc...
Sleeping: is the fact that a process puts itslef in an unrannable state for a period of time, how it is done in unix is via alarm syscall
Both for Waiting processes and Sleeping processes are in fact waiting for some external event or a signal to go into the ready state so that it can be picked up by the scheduler and fed to the CPU to continue its exceution (running state)
TLDR
Both of them are a WAITING state.
I have a bash script where i kill a running process by sending the SIGTERM signal to it's process ID. However, i want to know the return code of the process i just sent the signal.
Is that possible?
i cannot use 'wait' because the process to kill was not started from my script and i'm receiving
"pid ##### is not a child of this shell"
I did some tests in a command line, in a console where the process was running, after i send the SIGTERM signal (from another console), i checked the exit code and it was 143.
I want to kill the process from a different script and catch that number.
As shellter said, you cannot get the exit code of a process except using wait (or waitpid(), etc...) and you can only do that if you are its parent.
But even if you could, think about this:
When you send a process a SIGTERM, only one of three things can happen:
The process has not installed any signal handler for SIGTERM. In this case it dies immediately as a result of the signal. But in this case the exit code is uninteresting – you already know what it is. On most platforms it is 143 (128 + integer value of SIGTERM), indicating, unsurprisingly, that the process has died as a result of SIGTERM.
The process has configured SIGTERM to be ignored. In this case, nothing happens, the process does not die, and so there is no exit code to obtain anyway.
The process has installed a signal handler for SIGTERM. In this case, the handler is invoked. The handler might do anything at all: possibly nothing, possibly exit immediately, possibly carry out some cleanup operation and exit later, possibly something completely different. Even if the process does exit, that's only an indirect result of the signal, and it happens at a later time, so there is no exit code to obtain that comes directly from the delivery of the signal.
One thread do an emit signal1();
A second thread do an emit signal2(); after that first thread has sent its signal ( there is the same mutex locked before emit call on both thread and I logged it, I can see in my log that first thread acquire lock before second thread)
first thread and second thread or not the GUI thread.
Is there any guarentees that signal1's slot will be call before signal2's slot ?
As the emitter and the receiver objects are running in different threads, the slots will not be executed synchronously: Qt is using a queued connection by default instead of a direct connection. You can however force a synchronous execution by using a blocking queued connection (see also http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum for the description of the different connection types) when connecting signals and slots.
But a blocking queue connection has a cost: the emitter thread is blocked until all the connected slots are executed, which is not necessarily a good idea. If you want to use a non-blocking connection, however, the order of execution depends on the objects were the slots are executed.
The important thing to consider is that each QThread has its own event queue. It means that the order of execution is only guaranteed for the slots of a given thread. This means that you have to consider the following cases:
signal1's slot and signal2's slot are defined in QObject's living in the same thread: in that case, you can be sure that the slots are executed in the expected order because they are triggered by the same event queue
both slots are running in different threads: here you have no control over the order of execution as the signals are posted to 2 independent event queues. If this is the case, you have to use mutexes or wait conditions (or use a blocking connection).
emit is just syntactic sugar, look at the .cpp generated by the Meta Object Compiler (moc).
So, emit signal1(); is compiled as signal1();, and the answer to your question is YES, but of course you have no guarentees that signal1() execution ends before signal2() invocation.
I am not sure if I understand you correctly, but this might help you:
When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call.
from http://doc.qt.io/qt-5/signalsandslots.html
So think of calling emit() as calling any other function.