[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python's GC approach
>>>>> "MM" == Morgan McGuire <firstname.lastname@example.org> 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
- 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
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 :-).