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 that happen for 1.6. IIRC, this shouldn't be too hard -- just a few tweaks of the configure script (and who knows what for those minority platforms that don't use configure :). -Barry
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
That reminds me... what about the free threading patches? Perhaps they should be added to the list of issues to consider for 1.6. -- A.M. Kuchling http://starship.python.net/crew/amk/ Oh, my fingers! My arms! My legs! My everything! Argh... -- The Doctor, in "Nightmare of Eden"
Andrew M. Kuchling [akuchlin@mems-exchange.org] wrote:
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.
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. Chris -- | Christopher Petrilli | petrilli@amber.org
On Fri, 19 Nov 1999, Christopher Petrilli wrote:
Definitely. I think you still want a --disable-threads option, but the default really ought to include them.
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! :-)
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/
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
That reminds me... what about the free threading patches? Perhaps they should be added to the list of issues to consider for 1.6. -- A.M. Kuchling http://starship.python.net/crew/amk/ Oh, my fingers! My arms! My legs! My everything! Argh... -- The Doctor, in "Nightmare of Eden"
Andrew M. Kuchling [akuchlin@mems-exchange.org] wrote:
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.
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. Chris -- | Christopher Petrilli | petrilli@amber.org
On Fri, 19 Nov 1999, Christopher Petrilli wrote:
Definitely. I think you still want a --disable-threads option, but the default really ought to include them.
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! :-)
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/
participants (4)
-
Andrew M. Kuchling -
Barry A. Warsaw -
Christopher Petrilli -
Greg Stein