|
642 | 642 | executed in the context of the thread that calls the \funnm{fork}(). Such
|
643 | 643 | handlers are very useful when \funnm{fork}() is used not only as a wrapper
|
644 | 644 | around \funnm{exec}(). After \funnm{fork}(), all variables in the child are in
|
645 |
| -the state as in the parent, so if a thread not present to the child held a mutex |
| 645 | +the state as in the parent, so if a thread not present in the child held a mutex |
646 | 646 | in the parent (see page \pageref{MUTEXES}), the mutex stays locked in the child,
|
647 |
| -and trying to lock in the child will lead to a deadlock. However, if the parent |
648 |
| -locks all the mutexes in the \emph{\texttt{pre-fork}} handler and then unlocks |
649 |
| -them in the \emph{\texttt{post-fork}} handler (both for the parent and the |
650 |
| -child), you will avoid such deadlocks. That is because when locking mutexes in |
651 |
| -the \emph{\texttt{pre-fork}} handler, other threads are still running so the |
| 647 | +and trying to lock it in the child will lead to a deadlock. However, if the |
| 648 | +parent locks all the mutexes in the \emph{\texttt{pre-fork}} handler and then |
| 649 | +unlocks them in the \emph{\texttt{post-fork}} handler (both for the parent and |
| 650 | +the child), you will avoid such deadlocks. That is because when locking mutexes |
| 651 | +in the \emph{\texttt{pre-fork}} handler, other threads are still running so the |
652 | 652 | mutexes held by them should be released eventually (usually each thread exits a
|
653 | 653 | critical section in a short time in well written code).
|
654 | 654 | \item This scheme will only work if the \emph{\texttt{pre-fork}} handler
|
|
0 commit comments