If you fork with the purpose of calling an exec function, you can use fcntl with FD_CLOEXEC to have the file descriptor closed once you exec: int fd = open(…); fcntl(fd, F_SETFD, FD_CLOEXEC); Such a file descriptor will survive a fork but not functions of the exec family.
Syntax of waitpid(): pid_t waitpid(pid_t pid, int *status, int options); The value of pid can be: < -1: Wait for any child process whose process group ID is equal to the absolute value of pid. -1: Wait for any child process. 0: Wait for any child process whose process group ID is equal to that … Read more
No. Threads are not copied on fork(). POSIX specification says (emphasize is mine): fork – create a new process A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of … Read more
First, accept() the incoming connection. The accepting process now has a handle to the listening socket, and the newly accepted socket. Fork and: In the child: Close the listening socket. Do stuff with the accepted socket. In the parent: Close the accepted socket. Resume the accept loop. The various socket resources will be reclaimed when … Read more
It’s important to distinguish between the file descriptor, which is a small integer that the process uses in its read and write calls to identify the file, and the file description, which is a structure in the kernel. The file offset is part of the file description. It lives in the kernel. As an example, … Read more
The intent of vfork was to eliminate the overhead of copying the whole process image if you only want to do an exec* in the child. Because exec* replaces the whole image of the child process, there is no point in copying the image of the parent. if ((pid = vfork()) == 0) { execl(…, … Read more
WEXITSTATUS(stat_val) is a macro (so in fact it does not “return” something, but “evaluates” to something). For how it works you might like to look it up in the headers (which should be #included via <sys/wait.h>) that come with the C-compiler you use. The implementation of this macro might differ from one C-implementation to the … Read more
This is due to historical reasons. As explained at https://www.bell-labs.com/usr/dmr/www/hist.html, very early Unix did have neither fork() nor exec*(), and the way the shell executed commands was: Do the necessary initialization (opening stdin/stdout). Read a command line. Open the command, load some bootstrap code and jump to it. The bootstrap code read the opened command, … Read more
You should use _exit (or its synonym _Exit) to abort the child program when the exec fails, because in this situation, the child process may interfere with the parent process’ external data (files) by calling its atexit handlers, calling its signal handlers, and/or flushing buffers. For the same reason, you should also use _exit in … Read more
Each page that is allocated for the process (be it a virtual memory page that has the stack on it or the heap) is copied for the forked process to be able to access it. Actually, it is not copied right at the start, it is set to Copy-on-Write, meaning once one of the processes … Read more