1# Background # 2 3In Python, multithreading is ineffective at concurrency for CPU bound tasks 4due to the GIL (global interpreter lock). Extension modules can release 5the GIL in CPU bound tasks, but that isn't an option in pure Python. 6Users use libraries such as multiprocessing, subprocess, concurrent.futures.ProcessPoolExecutor, 7etc, to work around the GIL. These modules call ```fork()``` underneath the hood. Various issues have 8been reported when using these modules with gRPC Python. gRPC Python wraps 9gRPC core, which uses multithreading for performance, and hence doesn't support ```fork()```. 10Historically, we didn't support forking in gRPC, but some users seemed 11to be doing fine until their code started to break on version 1.6. This was 12likely caused by the addition of background c-threads and a background 13Python thread. 14 15# Current Status # 16 17## 1.11 ## 18The background Python thread was removed entirely. This allows forking 19after creating a channel. However, the channel must not have issued any 20RPCs prior to the fork. Attempting to fork with an active channel that 21has been used can result in deadlocks/corrupted wire data. 22 23## 1.9 ## 24A regression was noted in cases where users are doing fork/exec. This 25was due to ```pthread_atfork()``` handler that was added in 1.7 to partially 26support forking in gRPC. A deadlock can happen when pthread_atfork 27handler is running, and an application thread is calling into gRPC. 28We have provided a workaround for this issue by allowing users to turn 29off the handler using env flag ```GRPC_ENABLE_FORK_SUPPORT=False```. 30This should be set whenever a user expects to always call exec 31immediately following fork. It will disable the fork handlers. 32 33## 1.7 ## 34A ```pthread_atfork()``` handler was added in 1.7 to automatically shut down 35the background c-threads when fork was called. This does not shut down the 36background Python thread, so users could not have any open channels when 37forking. 38 39# Future Work # 40 41## 1.13 ## 42The workaround when using fork/exec by setting 43```GRPC_ENABLE_FORK_SUPPORT=False``` should no longer be needed. Following 44[this PR](https://github.com/grpc/grpc/pull/14647), fork 45handlers will not automatically run when multiple threads are calling 46into gRPC. 47