On Fri, 19 Nov 1999, Christopher Petrilli wrote: > Andrew M. Kuchling [akuchlin@mems-exchange.org] wrote: > > Barry A. Warsaw writes: > > >We had some discussion a while back about enabling thread support by > > >default, if the underlying OS supports it obviously. I'd like to see Definitely. I think you still want a --disable-threads option, but the default really ought to include them. > Yes pretty please! One of the biggest problems we have in the Zope world > is that for some unknown reason, most of hte Linux RPMs don't have threading > on in them, so people end up having to compile it anyway... while this > is a silly thing, it does create problems, and means that we deal with > a lot of "dumb" problems. Yah. It's a pain. My RedHat 6.1 box has 1.5.2 with threads. I haven't actually had to build my own Python(!). Man... imagine that. After almost five years of using Linux/Python, I can actually rely on the OS getting it right! :-) > > That reminds me... what about the free threading patches? Perhaps > > they should be added to the list of issues to consider for 1.6. > > My recolection was that unfortunately MOST of the time, they actually > slowed down things because of the number of locks involved... Guido > can no doubt shed more light onto this, but... there was a reason. Yes, there were problems in the first round with locks and lock contention. The main issue is that a list must always use a lock to keep itself consistent. Always. There is no way for an application to say "hey, list object! I've got a higher-level construct here that guarantees there will be no cross-thread use of this list. Ignore the locking." Another issue that can't be avoided is using atomic increment/decrement for the object refcounts. Guido has already asked me about free threading patches for 1.6. I don't know if his intent was to include them, or simply to have them available for those who need them. Certainly, this time around they will be simpler since Guido folded in some of the support stuff (e.g. PyThreadState and per-thread exceptions). There are some other supporting changes that could definitely go into the core interpreter. The slow part comes when you start to add integrity locks to list, dict, etc. That is when the question on whether to include free threading comes up. Design-wise, there is a change or two that I would probably make. Note that shoving free-threading into the standard interpreter would get more eyeballs at the thing, and that people may have great ideas for reducing the overheads. Cheers, -g -- Greg Stein, http://www.lyra.org/
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