threading support in python

[sjdevnull at yahoo.com]

Steve Holden wrote:
> sjdevnull at yahoo.com wrote:
> > Paul Rubin wrote:
> >
> >>Jean-Paul Calderone <exarkun at divmod.com> writes:
> >>
> >>>>which more explicitly shows the semantics actually desired.  Not that
> >>>>"huge" a benefit as far as I can tell.  Lisp programmers have gotten
> >>>>along fine without it for 40+ years...
> >>>
> >>>Uh yea.  No lisp programmer has ever written a with-* function... ever.
> >>
> >>The context was Lisp programmers have gotten along fine without
> >>counting on the refcounting GC semantics that sjdevnull advocates
> >>Python stay with.  GC is supposed to make it look like every object
> >>stays around forever, and any finalizer that causes an explicit
> >>internal state change in an extant object (like closing a file or
> >>socket) is not in the GC spirit to begin with.
> >
> >
> > I disagree, strongly.  If you want "every object stays around forever"
> > semantics, you can just not free anything.  GC is actually supposed to
> > free things that are unreachable at least when memory becomes tight,
> > and nearly every useful garbage collected language allows destructors
> > that could have effects visible to the rest of the program.  Reference
> > counting allows more deterministic semantics that can eliminate
> > repeating scope information multiple times.
> >
> Clearly you guys are determined to disagree. It seemed obvious to me
> that Paul's reference to making it "look like every object stays around
> forever" doesn't exclude their being garbage-collected once the program
> no longer contains any reference to them.
>
> You simplify the problems involved with GC-triggered destructors to the
> point of triviality. There are exceedingly subtle and difficult issues
> here: read some of the posts to the python-dev list about such issues

No doubt that it's hard.  On the other hand, current CPython captures
programmer-friendly behavior quite well.  My main assertions are that:
1. Saying that GC is just freeing memory after it won't be referenced
anymore is disingenuous; it is _already_ common practice in Python (and
other languages) for destructors to close files, sockets, and otherwise
deallocate non-memory resources.
2. The ref-counting semantics are extremely valuable to the programmer.
 Throwing them out without careful consideration is a bad
idea--ref-counting is _not_ simply one GC implementation among many, it
actually offers useful semantics and the cost of giving up those
semantics should be considered before throwing out refcounting.

I'm actually willing to be convinced on (2); I think that what
ref-counting offers is a massive improvement over nondeterministic GC,
and it seems that refcounting has historically been supportable, but if
there are real tangible benefits to python programmers from eliminating
it that outweigh the niceties of deterministic GC, then I'd be okay
with sacrificing it.  It just seems like people are very cavalier about
giving up something that is a very nice feature in order to make other
implementations simpler.

(1) I think is here to stay, if you're going to tell programmers that
their destructors can't make program-visible changes (e.g. closing the
database connection when a dbconn is destroyed), that's a _huge_ change
from current practice that needs serious debate.