本文共 3169 字，大约阅读时间需要 10 分钟。

Although the pthread_atfork mechanism is intended to make locking state consistent after a fork, it has several drawbacks that make it usable in only limited circumstances:

• There is no good way to reinitialize the state for more complex synchronization objects such as condition variables and barriers.
• Some implementations of error-checking mutexes will generate errors when the child fork handler tries to unlock a mutex that was locked by the parent.
• Recursive mutexes can’t be cleaned up in the child fork handler, because there is no way to determine the number of times one has been locked.
• If child processes are allowed to call only async-signal safe functions, then the child fork handler shouldn’t even be able to clean up synchronization objects, because none of the functions that are used to manipulate them are async-signal safe. The practical problem is that a synchronization object might be in an intermediate state when one thread calls fork, but the synchronization object can’t be cleaned up unless it is in a consistent state.

Threads and I/O

We introduced the pread and pwrite functions. These functions are helpful in a multithreaded environment, because all threads in a process share the same file descriptors.

Daemon Processes

Introduction

Since a daemon does not have a controlling terminal, we need to see how a daemon can report error conditions when something goes wrong.

For a discussion of the historical background of the term daemon as it applies to computer systems, see Raymond [1996].

Daemon Characteristics

The column headings, in order, are the user ID, process ID, parent process ID, process group ID, session ID, terminal name, and command string.

The system that this ps command was run on (Linux 3.2.0) supports the notion of a session ID, which we mentioned with the setsid function in Section 9.5. The session ID is simply the process ID of the session leader. Some BSD-based systems, such as Mac OS X 10.6.8, will print the address of the session structure corresponding to the process group that the process belongs to (Section 9.11) instead of the session ID.

Coding Rules

Some basic rules to coding a daemon prevent unwanted interactions from happening. We state these rules here and then show a function, daemonize, that implements them.

1.Call umask to set the file mode creation mask to a known value, usually 0.

2.Call fork and have the parent exit. 3.Call setsid to create a new session.

Under System V–based systems, some people recommend calling fork again at this point, terminating the parent, and continuing the daemon in the child. This guarantees that the daemon is not a session leader, which prevents it from acquiring a controlling terminal under the System V rules (Section 9.6). Alternatively, to avoid acquiring a controlling terminal, be sure to specify O_NOCTTY whenever opening a terminal device.

4.Change the current working directory to the root directory.

5.Unneeded file descriptors should be closed. 6.Some daemons open file descriptors 0, 1, and 2 to /dev/null so that any library routines that try to read from standard input or write to standard output or standard error will have no effect.

转载地址：https://blog.csdn.net/myfather103/article/details/79984252 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！