Introduce ginterpreter worker

[aisk]

Introduce a multi-interpreter–based worker that can handle multiple requests within the same process, each running in a separate interpreter, without sharing a GIL. This allows different interpreters to run in true parallelism.

This does not require a no-GIL build of Python, and it does not require users to handle thread-safe code at the Python level.

Features are missing:

• SSL
• Access log
• Graceful shutdown
• Keepalive
• pre_request/post_request hooks
• HTTP2
• sendfile
• Max requests
• Comprehensive unit testing
• Documentation

[pajod]

Oh, this looked simple enough to give it a spin in a fair comparison against real workloads after "just" adding logging + keepalive.. but apparently I do not have 3.14 on Debian yet. Monitoring for later..

[aisk]

Oh, this looked simple enough to give it a spin in a fair comparison against real workloads after "just" adding logging + keepalive.. but apparently I do not have 3.14 on Debian yet. Monitoring for later..

Do you think it makes sense to add logging and keepalive support now?

[pajod]

Do you think it makes sense to add logging and keepalive support now?

Not yet, I guess. Hoping that most of missing bits and pieces (incl ssl) can be added with less worker-specific code later, as the rest of Gunicorn receives some much-needed refactoring.
Probably a good idea to edit the PR message to clarify current limitations of the patch, though.

[benoitc]

The idea is interresting as it brings isolation. Do you want to complete it ?

Following changes are needed:

1. Add access logging support (critical for production use)
2. Add future tracking and connection counting (see review)
3. Improve graceful shutdown handling (see review)
4. Add integration tests
5. Update documentation

Also please update the PR with the current limitatisn you may have found.

[benoitc]

@aisk any news?

[aisk]

@benoitc Added basic document and features, I think this PR can be reviewed now.

[benoitc]

with subinterpreter why notconsidering instead of spawning new worker have one worker = 1 subinterpreter and insteadb ypassing gil. spawning subinterpreter can use ~ 50Mb of ram. thoughts?

[aisk]

with subinterpreter why notconsidering instead of spawning new worker have one worker = 1 subinterpreter and insteadb ypassing gil. spawning subinterpreter can use ~ 50Mb of ram. thoughts?

Current implementation is mainly based on the current gthread worker, so it may have multiple sub interpreters in multiple worker threads.

The only benefit with this design I can think of is that some code, especially some C extensions, may have resource leaks in the current process. Destroying the sub interpreter cannot eliminate this kind of leak. With this design, we can re-create the worker process to avoid the leak.