I am trying to trace a high level function call that blocks a certain process. An example of such is scanf, which blocks the terminal until it receives a '\n' . Now I traced scanf down to the getc (scanf uses getc to acquire characters from stdin). My question is, what is the process that takes to interpret the data that comes from the keyboard, all the way through the kernel and to the return of getc? Also how does scanf stops the terminal (is the computer idling, or working on another task)?
Thank You
Whenever a process issues a system call (such as a blocking read(2)), the process starts to execute in kernel mode, that is, the kernel code that handles the particular system call is invoked.
After that, depending on the underlying device and the driver, the process can be suspended and put in a wait-queue. When a key is pressed, the kernel code that handles interrupts is invoked and from there it is deducted which key is pressed.
The kernel then resumes the process that is waiting for this input, and delivers the data by copying it from the kernel address space to the particular process' address space.
The system call enables the user program to get executed in previliged mode. When the user program makes the system call, it generates the interrupt 0x80. When the kernel receives the interrupt, it will do a lookup on Interrupt Descriptor Table (IDT) for 0x80 and executes the corresponding handler (syscall). After the execution of this handler, the control will be transferred to user program after copying the information from kernel memory to user memory.
In this case, scanf is mapped to the library function, "read". The "read" system call invokes "sys_read" which then reads from the input stream STDIN using getc. Hope this helps!
Related
enter image description here
I learned that when a system call function is called, the process changes. But what is process B if I call the read function without the fork() function? isn't there is only one process?
On x86-64, there is one specific instruction to do system calls: syscall (https://www.felixcloutier.com/x86/syscall.html). When you call read() in C, it is compiled to placing the proper syscall number in a register along with the arguments you provide and to one syscall instruction. When syscall is executed, it jumps to the address stored in the IA32_LSTAR register. After that, it is in kernel mode executing the kernel's syscall handler.
At that point, it is still in the context of process A. Within its handler, the kernel realizes that you want to read from disk. It will thus start a DMA operation by writing some registers of the hard-disk controller. From there, process A is waiting for IO. There is no point in leaving the core idle so the kernel calls the scheduler and it will probably decide to switch the context of the core to another process B.
When the DMA IO operation is done, the hard-disk controller triggers an interrupt. The kernel thus puts process A back into the ready queue and calls the scheduler which will probably have the effect of switching the context of the core back to process A.
The image you provide isn't very clear so I can understand the confusion. Overall, on most architectures it will work similarly to what is stated above.
The image is somewhat misleading. What actually happens is, the read system call needs to wait for IO. There is nothing else that can be done in the context of process (or thread) A.
So kernel needs to find something else for the CPU to do. Usually there is some other process or processes which do have something to do (not waiting for a system call to return). It could also be another thread of process A that is given time to execute (from kernel point of view, thread and process aren't really much different, actually). There may be several processes which get to execute while process A waits for system call to complete, too.
And if there is nothing else for any other process and thread to do, then kernel will just be idle, let the CPU sleep for a bit, basically save power (especially important on a laptop).
So the image in the question shows just one possible situation.
When a program is doing I/O, my understanding is that the thread will briefly sleep and then resume (e.g. when writing to a file). My question is that when we do printing using printf(), does a C program thread sleep in any way ?
Since you've specifically asked for printf(), I'm going to assume that you mean in the most generic way where it will fill a reasonably sized buffer and invoke the system call write(2) to stdout and that the stdout happens to point to your terminal.
In most operating systems, when you invoke certain system calls the calling thread/process is removed from CPU runnable list and placed in a separate waiting list. This is true for all I/O calls like read/write/etc. Being temporarily removed from processing due to I/O is not the same as being put to sleep via a timer.
For example, in Linux there's uninterruptible sleep state of a thread/process specifically meant for I/O waiting, while interruptible sleep state for those thread/process that are waiting on timers and events. Though, from a dumb user's perspective they both seem to be same, their implementation behind the scenes are significantly different.
To answer your question, a call to printf() isn't exactly sleeping but waiting for the buffer to be flushed to device rather than actually being in sleep. Even then there are a few more quirks which you can read about it in signal(7) and even more about various process/thread states from Marek's blog.
Hope this helps.
Much of the point of stdio.h is that it buffers I/O: a call to printf will often simply put text into a memory buffer (owned by the library by default) and perform zero system calls, thus offering no opportunity to yield the CPU. Even when something like write(2) is called, the thread may continue running: the kernel can copy the data into kernel memory (from which it will be transferred to the disk later, e.g. by DMA) and return immediately.
Of course, even on a single-core system, most operating systems frequently interrupt the running thread in order to share it. So another thread can still run at any time, even if no blocking calls are made.
I've got a program where main process forks into 4 children that cooperate with each other:
process0 is opening FIFO file (O_WRONLY), reading 1 byte at a time from STDIN using read function, writing into FIFO using write and closing FIFO file
process1 is waiting for the shared memory to be empty (I'm using first byte of shared memory table if(tab[0] == 0) to check if its empty) opening FIFO file (O_RDONLY), reading from it, translating this one byte into hex and saving it into shared memory. It then closes fifo and sets tab[0] which is shared memory table to 1.
process2 is reading from shared memory if tab[0] == 1. After reading it writes data into pipe
process3 is reading from pipe and writing into STDIN
this all works perfect. The problem started when I wanted to add signals. I'm using semaphores to synchronize p0 and p1, signals to synchronize p1 and p2 and message queue to synchronize p2 and p3. It also works fine except for the times when for example process1 is in the sleeping mode. It goes into this mode when it wants to read from fifo and has to wait for data to be transferred.. I guess. I've been reading about it.
processes hierarchy
Here's what I've found that I think may be the cause:
"When the process makes a system call while in user mode (1), it moves into state 2 where it begins to run in kernel mode. Assume at this point that the system call made was to read a file on the hard disk. Because the read is not carried out immediately, the process goes to sleep, waiting on the event that the system has read the disk and the data is ready. It is now in state 4. When the data is ready, the process is awakened. This does not mean it runs immediately, but rather it is once again ready to run in main memory (3). "
I think I understand it but how can I avoid this? I want my program to react to signals always. Is there some way to change processes state from sleeping to running when I send the signal through "kill" ? Can I somehow tell the process to stop "waiting on the event that the system has read the disk and the data is ready" ?
here's my code if someone wants to look at it:
Program's code
If I understand your question correctly, process 1 is getting hung up at line 442 (source) and not responding to signals because it's in the read.
The obvious answer is just don't do a blocking read(). Check the descriptor to see if anything is there to read and move on if not. Read up on fcntl/ioctl and how to do non-blocking reads.
Your observations is likely that (most) system call defaults to restarting if a signal occurs. Shortly said, that means code stuck in a system call wakes up to user-space when a signal is delivered, but resumes the system call after the signal handler has been run.
If you use sigaction() to establish a signal handler instead of the signal() function., system calls will not restart when a signal is caught , but rather fail and set errno to EINTR.
That means you you have to handle the fact that system calls can "fail" anywhere due to a signal being delivered.
(signal() by default will cause system calls on linux restart, it can be controlled by some feature macros before including the signal.h header. Whether sigaction() causes the system call to restart is controlled by the flag SA_RESTART when establishing a signal handler)
A user defined handler function is specified for a particular signal.On reception of this signal the handler function is invoked. Does the handler function run in user space or kernal space ?
Or generally a action for any signal is executed in user space or kernal space?
The handler runs in user space and only has access to the virtual address space of the process.
Of course, the C standard proper doesn't know anything about "user" and "kernel".
Signal handlers have to run in user space. If they ran in kernel space, they could access anything in the entire machine (since the kernel has control over all processes). As a result, a malicious program could easily corrupt other programs' memory, steal data, or worse by simply sending a signal to itself.
Generally speaking signals are executed in userspace. However, since the C language standard doesn't actually define a separation between user and kernel-space, it's conceivable that there may be C language implementations in which this is not the case.
Note, however, that in Windows and all flavors of Unix, signals are guaranteed to run in userspace.
The kernel can send a signal to the user space, but not vice versa and the amount of data to be sent is quite limited and the signal handlers are run in user space.
Explanation :
In order to be able to send a signal from kernel space to user space, the kernel needs to know the pid of the user space process. As soon as the kernel module receives the pid, it looks for the corresponding process descriptor, and sends a signal to it. All information related to the signal is saved in a struct siginfo.
The user space process registers a signal handler function with the kernel. This adds the address of the signal handler function to the process descriptor. This function gets executed each time a certain signal is delivered.
Currently I am reading "Understanding the Linux kernel, 3rd edition" and on p.22 I can read:
In the simplest case, the CPU executes a kernel control path sequentially from the
first instruction to the last. When one of the following events occurs, however, the
CPU interleaves the kernel control paths:
A process executing in User Mode invokes a system call, and the corresponding
kernel control path verifies that the request cannot be satisfied immediately; it
then invokes the scheduler to select a new process to run. As a result, a process
switch occurs. The first kernel control path is left unfinished, and the CPU
resumes the execution of some other kernel control path. In this case, the two
control paths are executed on behalf of two different processes.
The kernel control path can be interrupted from a user space process doing a system call?
I thought the priority was pretty much:
interrupts
kernel threads
user space processes
I have checked the errata and could not find anything about this.
You are right about the priority list, but what (I think) the book is trying to say is:
When a (user) process makes a system call, the kernel starts executing on its behalf.
If the system call can be completed (the kernel control path does not run into a roadblock), then it will usually return direct to the calling process - think getpid() function call.
On the other hand, if the system call cannot be completed (for example, because the disk system must read a block into the kernel buffer pool before its data can be returned to the calling process), then the scheduler is used to select a new process to run - preempting the (kernel thread of control that was running on behalf of the) user process.
In due course, the original system call will be able to continue, and the original (kernel thread of control that was running on behalf of the) user process will be able to continue and eventually complete, returning control to the user space process running in user space and not in the kernel.
So "No": it is not the case that the 'kernel path can be interrupted from a user space process doing a system call'.
The kernel path can be interrupted while it is executing a system call on behalf of a user space process because: an interrupt occurs, or the kernel path must wait for a resource to become available, or ...