On Fri, Aug 17, 2001 at 04:36:21PM -0400, Guido van Rossum wrote:
> > Last time, I tried to optimize the memory associate with each
> > list/dict. That slowed some things down. Atomic incr/decr wasn't
> > really available under Linux (Win has InterlockedIncrement and
> > friends), so the Linux incr/decr was a bit slower than it should it
> > have been.
>
> This would be an opportunity for some highly platform-specific
> assembler,
Yah.
> assuming we'll always have
> configure --{enable,disable}-free-threading.
Good assumption :-) As its been pointed out recently on this list, and in
the past, free threading isn't the "end all" of threading. There are some
tradeoffs involved.
> > There are a number of things that I'd do differently the next time around.
>
> When will that be?
I started my note with if/when :-) Between the Python http-based modules,
ViewCVS, edna, Subversion, Apache, and mod_dav... I'm a bit booked up for a
while :-) and don't have an "itch" to get free threading completed.
The "baby steps" note that I posted last year was a hope to get others
involved, who may have more immediate needs for this kind of functionality.
Kind of a road map from my earlier experience.
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