2.6, 3.0, and truly independent intepreters

[Andy O'Meara]

On Oct 24, 9:40 pm, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> > It seems to me that the very simplest move would be to remove global
> > static data so the app could provide all thread-related data, which
> > Andy suggests through references to the QuickTime API. This would
> > suggest compiling python without thread support so as to leave it up
> > to the application.
>
> I'm not sure whether you realize that this is not simple at all.
> Consider this fragment
>
>     if (string == Py_None || index >= state->lastmark ||
> !state->mark[index] || !state->mark[index+1]) {
>         if (empty)
>             /* want empty string */
>             i = j = 0;
>         else {
>             Py_INCREF(Py_None);
>             return Py_None;
>


The way to think about is that, ideally in PyC, there are never any
global variables.  Instead, all "globals" are now part of a context
(ie. a interpreter) and it would presumably be illegal to ever use
them in a different context. I'd say this is already the expectation
and convention for any modern, industry-grade software package
marketed as extension for apps.  Industry app developers just want to
drop in a 3rd party package, make as many contexts as they want (in as
many threads as they want), and expect to use each context without
restriction (since they're ensuring contexts never interact with each
other).  For example, if I use zlib, libpng, or libjpg, I can make as
many contexts as I want and put them in whatever threads I want.  In
the app, the only thing I'm on the hook for is to: (a) never use
objects from one context in another context, and (b) ensure that I'm
never make any calls into a module from more than one thread at the
same time.  Both of these requirements are trivial to follow in the
"embarrassingly easy" parallelization scenarios, and that's why I
started this thread in the first place.  :^)

Andy