On Sun, 27 Feb 2000, Tim Peters wrote:
... It's a nice approach, but I'd rather see you put the bulk of the Py_TRASHCAN_SAFE_END macro into a real function or two, invoked from the macro. This code is only going to get hairier if GregS takes up his free-threading quest again. Like
Call it a guarantee that I'll be doing the free-threading again. I won't start on it until, say, June or so, but I've outlined a number of tasks in private email to Guido that could be done before the "hard core" stuff starts. Over the weekend, I realized that I should post that "plan of attack" to the thread-sig. Others may be interested in helping to move the free-threading along. Note that it is unclear whether free-threading will be a patch set against 1.6, or a ./configure option (and a set of #ifdefs) within the standard distribution. I believe that it mostly depends on the timing of completing the work vs. the timing of the 1.6 release (if I understand Guido properly). This is part of the reason why I came up with an attack plan: there are things that can be done, tested, and integrated into Python without going full-on free-threading. (and thus minimizing any post-1.6 patch set) I'll compose the email later this week... Cheers, -g p.s. I'm personally motivated to do the free-threading again because I'm going to write a mod_python for Apache 2.0. Apache 2.0 uses a threading model (rather than a forking model) whenever it can. Thus, a mod_python built against a free-threaded Python will offer far superior performance compared to the global-lock version. -- Greg Stein, http://www.lyra.org/