Re: Python's GC approach

[address@hidden (Jeremy Hylton)]

>>>>> "MM" == Morgan McGuire <morgan3d@yahoo.com> writes:

  >> I'm amused because I chose the Boehm gc in REBOL 1.0 because I
  >> thought it *was* rather portable and reliable.

  MM> I think that it is more portable than many other solutions but
  MM> makes a bad first impression because it happens to have well
  MM> documented the few platform-dependent issues.

The bad first impression had as much to do with its
platform-dependence as with the various limitations it places on the C
code you write and how it interacts with libraries.  If I
misunderstand the warnings or if you can comment on your experience,
I'd appreciate it.

The limitations that worried me most were about:

    - only working with a limited set of threads packages on various
      platforms,

    - requiring that code that uses threads by modified to include the
      gc header file because it replaces some of the pthreads calls
      with macros that help it track things,

    - concern about whether (given the about constraints) it is
      feasible to extend or embed an interpreter that uses the Boehm
      GC with a large, multi-threaded C app that isn't similarly
      modified and recompiled.

The limited experience of Python developers using the Boehm collector
was frusterating, because it failed when we integrated Python with
Tcl/TK.

On the other hand, Python pays a real price for not using the Boehm
GC.  We have to maintain our own mark-and-sweep collector for catching
cycles.  We have to manually track reference counts in all our C
code.  But Python runs on platforms that the Boehm GC hasn't been
ported to and plays nicely with C libraries.  Worse is better :-).

Jeremy