Greg> About the only reason that I can see to *not* make them the
Greg> default is the slight speed loss. But that seems a bit bogus, as
Greg> the interpreter loop doesn't spend *that* much time mucking with
Greg> the interp_lock to allow thread switches. There have also been
Greg> some real good suggestions for making it take near-zero time until
Greg> you actually create that second thread.
Okay, everyone has convinced me that holding threads hostage to the Mac is a
red herring. I have other fish to fry. (It's 1:30AM and I haven't had
dinner yet. Can you tell? ;-)
Is there a way with configure to determine whether or not particular Unix
variants should have threads enabled or not? If so, I think that's the way
to go. I think it would be unfortunate to enable it by default, have it
appear to work on some known to be unsupported platforms, but then bite the
programmer in an inconvenient place at an inconvenient time.
Such a self-deciding configure script should exit with some information
about thread enablement:
Yes, we support threads on RedHat Linux 6.0.
No, you stinking Minix user, you will never have threads.
Rhapsody, huh? I never heard of that. Some weird OS from Sunnyvale,
you say? I don't know how to do threads there yet, but when you
figure it out, send patches along to python-dev at python.org.
Of course, users should be able to override anything using --with-thread or
without-thread and possibly specify compile-time and link-time flags through
arguments or the environment.
Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip at mojam.com | Musi-Cal: http://www.musi-cal.com/
518-372-5583
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