The intention is to fork on the server side, but it is generally used to achieve asynchronous.
To Process HTTP Servers
However, I would like you to move in parallel after 3.As soon as I accept it, I will start fork or thread and leave the process to you.By doing so, the next accept can be processed immediately.
Failure to do so will result in poor performance as other requests cannot be processed while doing 3 or 4.
However, since fork requires a lot of resources (disadvantages), there is also a way to reduce overhead (prefork) by using threads or passing a socket to a process that has been forked in advance.On the other hand, if you fork, it has the advantage of being able to handle it with a different execution permission than the process you accepted.
In most cases, the intent of the client to fork is to do something else while HTTP is in progress.
There are already comments, but in general
What is called "server software" is designed to do fork
What is called "client software" is made without fork
I personally think that there are a lot of things.
It is mandatory to fork the software that you want to run as daemon.
The process is independent.They become independent not only of their parents but also of their siblings who have the same process.
The process is protected at the OS level, so even if the server software itself is bugged,
·You are the only one who stops abnormally (service stabilizes)
·It makes it harder to disclose your information to your brothers (improves security)
Therefore, it is beneficial to do fork in terms of server software.
·forkUse more resources (memory, handle, etc.)
·The program does fork/exec, so it adds one more effort. (setuid/setugid is one more effort and two more effort.)
·Debugger makes it difficult to follow (different processes need to be debugged)
Therefore, there is little reason to fork in terms of client software.
So you just have to use it differently depending on the purpose and purpose of the program.
© 2024 OneMinuteCode. All rights reserved.