> Not knowing anything much about memory
> management, would it be possible to have a sort of mixed ref count/garbage
> collection system where you only use the gc stuff as a last resort? My
> thought is that it would be useful to use gc to find and reclaim circular
> garbage.
That's *sorta* what Perl does, 'though you can still be bitten by
circular refs in a long-running process. Err, long-running thread. You
see, Perl has a mark-and-sweep garbage collector which is run only on
thread shutdown.
From the "perlobj" man page:
[code sample omitted because I'm sure many python-dev readers
automatically filter out any message that matches /[\$\@\%]\w+/
it's just a constructor that creates objects for a recursive data
structure]
If you create nodes like that, they (currently) won't go
away unless you break their self reference yourself. (In
other words, this is not to be construed as a feature, and
you shouldn't depend on it.)
Almost.
When an interpreter thread finally shuts down (usually when
your program exits), then a rather costly but complete
mark-and-sweep style of garbage collection is performed, and
everything allocated by that thread gets destroyed. This is
essential to support Perl as an embedded or a
multithreadable language. For example, this program
demonstrates Perl's two-phased garbage collection:
[more interesting code omitted]
Interesting idea, but I don't think it's what Skip had in mind.
Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
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