Processes in the Linux operating system (basic concepts)
The main active entities in the Linux system are processes. Each process executes one program and initially receives one control flow. In other words, a process has one instruction counter, which keeps track of the next executable instruction. Linux allows the process to create additional threads (after it starts execution).
Linux is a multi-tasking system, so several independent processes can run simultaneously. Moreover, each user can have several active processes at the same time, so that hundreds and even thousands of processes can work simultaneously in a large system. In fact, most single-user workstations (even when the user has gone somewhere else) have dozens of background processes called daemons running . They start when the system is booted from a shell script.
A typical daemon is cron . He wakes up once a minute, checking if he needs to do something. If he has a job, then he does it, and then goes to sleep on (until the next check).
')
This daemon allows you to schedule Linux activity for minutes, hours, days, and even months ahead. For example, imagine that a user is scheduled to appear at the draft board at 3 pm on the following Tuesday. He can create an entry in the cron daemon database so that it signals to him, say, at 14:30. When the appointed day and time comes, the cron daemon sees that it has work and starts the beep program at the appointed time (as a new process).
The cron daemon is also used to periodically run tasks, for example, a daily disk backup at 4 am or reminding forgetful users to buy presents for the new year every week until December 31. Other daemons manage incoming and outgoing e-mail, printer queues, check if there are enough free memory pages, etc. Demons are implemented in the Linux system is quite simple, since each of them is a separate process, independent of all other processes.
Processes are created in the Linux operating system is very simple. The fork system call creates an exact copy of the original process, called the parent process . The new process is called the child process . The parent and child processes have their own (private) memory images. If the parent process subsequently changes any of its variables, these changes remain invisible to the child process (and vice versa).
Open files are used by the parent and child processes together. This means that if any file was opened in the parent process prior to the execution of the fork system call, it will remain open in both processes in the future. Changes made to this file by any of the processes will be visible to another. This behavior is only reasonable, since these changes will also be visible to any other process that also opens this file.
The fact that memory images, variables, registers and everything else are identical for both the parent process and the child leads to a bit of difficulty: how can the processes know which of them should execute the parent code, and which child? The secret is that the fork system call returns the number 0 to the child process and the non-zero PID (Process IDentifier) of the child process to the parent process. Both processes usually check the return value and act accordingly:
If the child wants to know its PID, then it can use the getpid system call. Process IDs are used in a variety of ways. For example, when a child process terminates, its parent receives the PID of the just-terminated child process. This can be important, since the parent process can have many child processes. Since child processes can also have child processes, the original process can create a whole tree of children, grandchildren, great-grandchildren, and more distant descendants.
On Linux, processes can communicate with each other using some form of messaging. You can create a channel between two processes in which one process can write a stream of bytes, and another process can read it. These channels are sometimes called pipes . Process synchronization is achieved by blocking the process when trying to read data from an empty channel. When data appears in the channel, the process is unlocked.
With the help of channels are organized conveyors shell. When the shell sees a line like
sort <f | head
it creates two processes, sort and head , and also establishes a channel between them in such a way that the standard output stream of the sort program is connected to the standard input stream of the head program. In this case, all the data written by sort go directly to the head, which does not require a temporary file. If the channel is full, the system suspends the work of sort until head removes at least some data from it.
Processes can also communicate in another way - using software interrupts. One process can send another a so-called signal . Processes can tell the system what action to take when a signal arrives. The options are: ignore the signal, intercept it, allow the signal to kill the process (the default action for most signals). If a process chooses to intercept signals sent to it, it must specify a signal processing procedure. When the signal arrives, control is immediately transferred to the handler. When the signal processing procedure completes its operation, control is again transferred to the place where it was located when the signal came (this is similar to the processing of hardware I / O interrupts). A process can send signals only to members of its process group (process group) , consisting of its direct parent (and other ancestors), brothers and sisters, as well as children (and other descendants). A process can also send a signal to its entire group at once in one system call.
Signals are used for other purposes. For example, if a process performs floating-point calculations and inadvertently divides by 0, then it receives a SIGFPE signal (Floating-Point Exception SIGnal - an exception signal when performing a floating-point operation).
Linux is a multi-tasking system, so several independent processes can run simultaneously. Moreover, each user can have several active processes at the same time, so that hundreds and even thousands of processes can work simultaneously in a large system. In fact, most single-user workstations (even when the user has gone somewhere else) have dozens of background processes called daemons running . They start when the system is booted from a shell script.
A typical daemon is cron . He wakes up once a minute, checking if he needs to do something. If he has a job, then he does it, and then goes to sleep on (until the next check).
')
This daemon allows you to schedule Linux activity for minutes, hours, days, and even months ahead. For example, imagine that a user is scheduled to appear at the draft board at 3 pm on the following Tuesday. He can create an entry in the cron daemon database so that it signals to him, say, at 14:30. When the appointed day and time comes, the cron daemon sees that it has work and starts the beep program at the appointed time (as a new process).
The cron daemon is also used to periodically run tasks, for example, a daily disk backup at 4 am or reminding forgetful users to buy presents for the new year every week until December 31. Other daemons manage incoming and outgoing e-mail, printer queues, check if there are enough free memory pages, etc. Demons are implemented in the Linux system is quite simple, since each of them is a separate process, independent of all other processes.
Processes are created in the Linux operating system is very simple. The fork system call creates an exact copy of the original process, called the parent process . The new process is called the child process . The parent and child processes have their own (private) memory images. If the parent process subsequently changes any of its variables, these changes remain invisible to the child process (and vice versa).
Open files are used by the parent and child processes together. This means that if any file was opened in the parent process prior to the execution of the fork system call, it will remain open in both processes in the future. Changes made to this file by any of the processes will be visible to another. This behavior is only reasonable, since these changes will also be visible to any other process that also opens this file.
The fact that memory images, variables, registers and everything else are identical for both the parent process and the child leads to a bit of difficulty: how can the processes know which of them should execute the parent code, and which child? The secret is that the fork system call returns the number 0 to the child process and the non-zero PID (Process IDentifier) of the child process to the parent process. Both processes usually check the return value and act accordingly:
pid = fork( ); /* fork , pid > 0 */
if (pid < 0) {
handle_error(); /* fork (, -
) */
} else if (pid > 0) {
/* */
} else {
/* */
}If the child wants to know its PID, then it can use the getpid system call. Process IDs are used in a variety of ways. For example, when a child process terminates, its parent receives the PID of the just-terminated child process. This can be important, since the parent process can have many child processes. Since child processes can also have child processes, the original process can create a whole tree of children, grandchildren, great-grandchildren, and more distant descendants.
On Linux, processes can communicate with each other using some form of messaging. You can create a channel between two processes in which one process can write a stream of bytes, and another process can read it. These channels are sometimes called pipes . Process synchronization is achieved by blocking the process when trying to read data from an empty channel. When data appears in the channel, the process is unlocked.
With the help of channels are organized conveyors shell. When the shell sees a line like
sort <f | head
it creates two processes, sort and head , and also establishes a channel between them in such a way that the standard output stream of the sort program is connected to the standard input stream of the head program. In this case, all the data written by sort go directly to the head, which does not require a temporary file. If the channel is full, the system suspends the work of sort until head removes at least some data from it.
Processes can also communicate in another way - using software interrupts. One process can send another a so-called signal . Processes can tell the system what action to take when a signal arrives. The options are: ignore the signal, intercept it, allow the signal to kill the process (the default action for most signals). If a process chooses to intercept signals sent to it, it must specify a signal processing procedure. When the signal arrives, control is immediately transferred to the handler. When the signal processing procedure completes its operation, control is again transferred to the place where it was located when the signal came (this is similar to the processing of hardware I / O interrupts). A process can send signals only to members of its process group (process group) , consisting of its direct parent (and other ancestors), brothers and sisters, as well as children (and other descendants). A process can also send a signal to its entire group at once in one system call.
Signals are used for other purposes. For example, if a process performs floating-point calculations and inadvertently divides by 0, then it receives a SIGFPE signal (Floating-Point Exception SIGnal - an exception signal when performing a floating-point operation).
Source: https://habr.com/ru/post/125369/
All Articles