Don't use a ThreadGroup for tracking worker threads #15
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.
Mongrel current uses a ThreadGroup to track its worker threads. But this has the unintended side-effect that any thread spawned by a request will inherit the group of the request thread. Thus, mongrel will think these new threads are requests and take them into account when it enforces num_process restrictions. This mostly went unnoticed for us in 1.1.3 but after upgrading 1.1.5 the num_process enforcement fix caused mongrels to start rejecting requests after we spawned a background thread pool.
I've fixed this by tracking threads in an array and then purging any completed threads whenever this array is accessed. This is not ideal, but I think any other fix would require the thread removing itself from the list of workers and thus require a mutex. Using an array seemed like the most straight-forward fix.