> Is there a reason why PyInterpreterState is not defined like so:
>
> typedef struct _is {
> ..
> PyThread_type_lock interpreter_lock;
> PyThreadState *_PyThreadState_Current;
> ..
> } PyInterpreterState;
I guess it is mainly for historical reasons.
> Would it be so hard to proceed like indicated below?
> Please help a naive geek.
While that sounds reasonable, you are likely to strike a number of other
problems. IIRC, you got a couple of replies on c.l.py, including one from
Aahz warning that statics in extension modules are likely to be a problem.
So my only suggestion is "suck it and see". I would expect that patches to
the Python core that "correct" any implementation issues, while retaining
full compatibilty, would have a good chance. It sounds reasonable that
moving the lock itself into the interpreter state would qualify, but whether
that solves your actual problem is anyone's guess. As you can see from
these implementation details, you are breaking new ground. It may be worth
fully exploring why you think you need multiple interpreter states - if you
"simply" need per-thread modules, and are in total control of your
environment, there may be other options. Exploration of these other options
is more on-topic for comp.lang.python.
Unfortunately, you are probably going to have to nut these issues out
yourself - time is pretty scarce around here.
Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4