Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes #80: https://bitbucket.org/eventlet/eventlet/issue/80/eexist-should-be-ignored-for-epoll. The issue is that a parent and child process can end up sharing an instance of epoll after a fork. Since file descriptors are unique only within a process, the two processes can end up with the same file descriptor pointing to two completely different resources. So the child registers socket A with FD 3 and the parent registers socket B with FD 3, and epoll gets messed up. These conflicts are likely because Linux will use the lowest free number for creating a new file descriptors.
We found this happening at Mixpanel in one of our services that's deployed using a prefork server. If some code causes the server process to create an eventlet hub prior to the fork, the master and workers all share the same epoll instance, and strange behavior ensues.
More generally, like threads, it doesn't make much sense to have a child process inherit its parent's state. Therefore, we decided to clean the parent's hub out of the child after fork. Any subsequent use of eventlet in the child will generate a new hub.