Shulou(Shulou.com)06/01 Report--

What happens when you start a process on Linux? For this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more small partners who want to solve this problem find a simpler and easier way.

What we need to do is start a process. We've talked a lot about system calls on our blog, and every time you start a process or open a file, it's a system call. So you might think there are system calls like this:

start_process(["ls", "-l", "my_cool_directory"])

This is a reasonable idea, obviously this is how it works in DOS or Windows. What I'm trying to say is that this doesn't work on Linux. However, I checked the documentation and there is indeed a system call for posix_spawn that basically does this, although that is outside the scope of this article.

fork and exec

Posix_spawn on Linux is implemented via two system calls, fork and exec (actually execve), which are commonly used. Although posix_spawn is used on OS X and fork and exec are deprecated, we will discuss Linux.

Every process in Linux exists in a "process tree." You can view the process tree by running pstree. The root of the tree is init and the process number is 1. Every process (except init) has a parent, and a process can have many children.

So suppose I want to start a process called ls to list a directory. Do I just have to start a process ls? No, it's not.

What I do is I create a child process that is a clone of me, and then the brain of that child process is eaten and becomes ls.

It started like this:

my parent |- me

Then run fork() to generate a child process that is a clone of myself:

my parent |- me |-- clone of me

Then I let the child run exec("ls"), which looks like this:

my parent |- me |-- ls

When the ls command ended, I was almost myself again:

my parent |- me |-- ls (zombie)

At this point ls is actually a zombie process. This means it's dead, but it's still waiting for me in case I need to check its return value (using the wait system call). Once I get its return value, I'll be alone again.

my parent |- Code implementation of mefork and exec

This is an exercise you must do if you are going to write a shell (a very interesting and enlightening project). Kamal has a great workshop on Github: https://github.com/kamalmarhubi/shell-workshop).

It turns out that with skills in C or Python, you can write a very simple shell like bash in a few hours. (At least if you have someone next to you who knows something, it takes longer if you don't.) I'm done. It's great.

This is how fork and exec are implemented in programs. I wrote a pseudocode for C. Remember, forks can fail.

int pid = fork();//I am divided//Who is "I"? If (pid == 0) { //I am now a child process // "ls" ate my brain and became a completely different process exec(["ls"])} else if (pid == -1) { //God, the fork failed, it was a disaster!} else { //I am the parent process Keep being a cool guy. //If necessary, I can wait for the child process to end.} What does "brain eaten" mean?

Processes have many attributes:

Open files (including open network connections)

environment variable

Signal handler (what happens when Ctrl + C is run on the program?)

Memory (your address space)

register

Executable file (/proc/$pid/exe)

groups and namespaces (related to Linux containers)

the current working directory

Users running programs

Something else I haven't thought of yet.

When you run execve and let another program eat your brain, virtually everything is the same! You have the same environment variables, signal handlers, open files, etc.

*** What changes is memory, registers, and running programs, which is a big deal.

Why fork isn't so resource intensive (copy on write)

You might ask,"If I have a process that uses 2 GB of memory, does that mean that every time I start a child process, all 2 GB of memory has to be copied? That sounds like a lot of resources! "

In fact, Linux implements copy-on-write for fork() calls, which for the new process's 2GB of memory is like "just look at the old process, it's the same!" "。Then, if any process attempts to write to memory, the system actually copies a copy of memory to that process. If the memory of both processes is the same, there is no need to copy.

Why do you need to know so much

You might say, well, these details sound great, but why are they so important? Will details about signal handlers or environment variables be inherited? What practical impact does this have on my day-to-day programming?

It's possible! For example, there is an interesting bug on Kamal's blog. It discusses how Python makes signal handlers ignore SIGPIPE. That is, if you run a program from Python, it ignores SIGPIPE by default! This means that programs behave differently when launched from Python scripts than when launched from shells. In this case, it creates a strange problem.

So, your program's environment (environment variables, signal handlers, etc.) may be important, inherited from the parent process. Knowing this is useful when debugging.

The answer to what happens when you start a process on Linux is shared here. I hope the above content can be helpful to everyone. If you still have a lot of doubts, you can pay attention to the industry information channel to learn more.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.