Brandon Williams wrote: > 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.
I don't think we consider builds against glibc to be the only standard way to build git. So I do think we need to fix this (and not, e.g., to modify our build instructions to require use of a malloc implementation that registers an atfork handler that unlocks all of its locks). Thanks for your work on that. Jonathan Tan had an idea about how to side-step the issue: what if "grep" forks an appropriate set of child processes before creating any threads and then communicates with those children using pipes? Because no threads have been spawned yet in the children, the child processes can use ordinary run_command. When run_command finishes, the child is still available to launch another command using run_command. Thoughts? Jonathan
