diff options
| author |  kpayson64 <kpayson@google.com> | 2018-05-10 15:13:59 -0700 |
|---|---|---|
| committer | kpayson64 <kpayson@google.com> | 2018-05-10 15:13:59 -0700 |
| commit | 35babffd0eff1e0b04092e9d5f9257b477441033 (patch) | |
| tree | bb0cba360d22801aa6024c289f18ee87c1e7ff5b /doc/fork_support.md | |
| parent | 3323bafef8ef90fbe745d74f58b56ea67a13e5c5 (diff) | |
Changes
Diffstat (limited to 'doc/fork_support.md')
| -rw-r--r-- | doc/fork_support.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/fork_support.md b/doc/fork_support.md index ba8483815d..d0f59f25da 100644 --- a/doc/fork_support.md +++ b/doc/fork_support.md @@ -4,9 +4,9 @@ In Python, multithreading is ineffective at concurrency for CPU bound tasks due to the GIL (global interpreter lock). Extension modules can release the GIL in CPU bound tasks, but that isn't an option in pure Python. Users use libraries such as multiprocessing, subprocess, concurrent.futures.ProcessPoolExecutor, -etc, to work around the GIL. These modules call fork() underneath the hood. Various issues have +etc, to work around the GIL. These modules call ```fork()``` underneath the hood. Various issues have been reported when using these modules with gRPC Python. gRPC Python wraps -gRPC core, which uses multithreading for performance, and hence doesn't support fork(). +gRPC core, which uses multithreading for performance, and hence doesn't support ```fork()```. Historically, we didn't support forking in gRPC, but some users seemed to be doing fine until their code started to break on version 1.6. This was likely caused by the addition of background c-threads and a background @@ -22,7 +22,7 @@ has been used can result in deadlocks/corrupted wire data. ## 1.9 ## A regression was noted in cases where users are doing fork/exec. This -was due to pthread_atfork() handler that was added in 1.7 to partially +was due to ```pthread_atfork()``` handler that was added in 1.7 to partially support forking in gRPC. A deadlock can happen when pthread_atfork handler is running, and an application thread is calling into gRPC. We have provided a workaround for this issue by allowing users to turn @@ -31,10 +31,10 @@ This should be set whenever a user expects to always call exec immediately following fork. It will disable the fork handlers. ## 1.7 ## -A pthread_atfork() handler was added in 1.7 to automatically shut down +A ```pthread_atfork()``` handler was added in 1.7 to automatically shut down the background c-threads when fork was called. This does not shut down the background Python thread, so users could not have any open channels when -forking(). +forking. # Future Work # |