Well that was strange and has never happened to me before. Was asking Claude questions about Python sub-interpreters and it came back as saying Apache/mod_wsgi was heaviest user of sub-interpreters. I jokingly responded by saying "I wrote mod_wsgi". It then proceeded to ask me lots of questions about how various aspects of the internals of mod_wsgi worked and how things might change with free threading and per interpreter GIL (which I had not mentioned). If only it could learn and remember.

Hey #pyconus, has there been much talk about Python free threading and per interpreter GIL support. I have added support for both in my mod_wsgi module for hosting Python WSGI applications under Apache/httpd. I am interested in connecting with anyone who may want to explore how these features can be used with WSGI applications in a production grade WSGI server setting. Or are these features still not seen as ready for prime time?

So was one of the pathological cases of the new GC in Python (the one being replaced with old one again in 3.15) is that it could so get its knickers in a knot that it would let a process ramp up to a very high memory usage and then decide to never reclaim it. Load balancing between two web processes with hello world. Both start at about 25MB. Strangely would often see them drop down to 15MB. This time one went up to about 250MB instead and stayed there. About to add some telemetry for GC.

Now have it working such that with one Apache/mod_wsgi instance, you can partition up things so that for any groups of processes, embedded, or daemon process groups, you can selectively say whether they run with free threading, or the GIL. Further, for those processes running with the GIL, you can opt specific sub interpreters into using their own GIL. So full flexibility to dice and slice it how you want. Still open question as to how to best make use of it, but you will have the option.