On Oct 24, 9:40 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list