[PATCH 0/5] forking and threading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Forking and threading is a difficult thing to get right due to potential
deadlocks which can occur if one thread holds a lock while another forks.  The
resulting process will still have the lock in a locked state with no hope of it
ever being released (since forking doesn't replicate the threads as well).

The aim of this series is to push the allocation done between fork/exec to
before the call to 'fork()' so that calls to malloc can't deadlock in a forked
child process.

Most standard implementations of malloc (e.g. glibc) do the appropriate thing
and register fork handlers in order ensure that locks are in a usable state
after forking.  Unfortunately other implementations don't do this so to account
for this lets just avoid calls to functions which may require locking.

As far as I understand the only instance of threading and forking which exists
in the current code base is 'git grep --recurse-submodules', and the standard
builds against glibc shouldn't exhibit any of this deadlocking.

Brandon Williams (5):
  run-command: convert sane_execvp to sane_execvpe
  run-command: prepare argv before forking
  run-command: allocate child_err before forking
  run-command: prepare child environment before forking
  run-command: add note about forking and threading

 cache.h       |   3 +-
 exec_cmd.c    |   2 +-
 run-command.c | 151 +++++++++++++++++++++++++++++++++++++++++++++-------------
 3 files changed, 119 insertions(+), 37 deletions(-)

-- 
2.12.2.715.g7642488e1d-goog




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]