On Tue, Dec 17, 2002 at 11:49:50PM -0800, Steve Fink wrote:
As a more concrete demonstration of what I'm talking about, here's an
implementiation of the easy part: the pinning and releasing macros.
(UNPIN would probably be better than RELEASE, huh?) It's a naive
implementation with a low fixed
Steve Fink wrote:
(UNPIN would probably be better than RELEASE, huh?)
Maybe ATTACH / DETACH or AQUIRE / RELEASE?
A
We have indeed gone through this before. The last time the dominant argument
was that these types of mark/unmark operations can be mis-used just as readily
as malloc/free, because the programmer has to know when and where to call them.
I'm just repeating this for everyone's benefit, not giving an
Steve Fink wrote:
I propose that we have configure probes for the variations that we can
support, but have everything else (including miniparrot) fall back to
a registration scheme. In other words, whenever you allocate a
collectible pointer and don't immediately anchor it to something, you
, you
have to pass it to a PIN_POBJ(p) macro, and once it's anchored, you
call RELEASE_POBJ(p). Or something like that. That way, we're always
correct. In configurations that someone cared about enough to
implement register scanning, we will also avoid the common-case
overhead of pin/release
As a more concrete demonstration of what I'm talking about, here's an
implementiation of the easy part: the pinning and releasing macros.
(UNPIN would probably be better than RELEASE, huh?) It's a naive
implementation with a low fixed limit on the max number of pinned
objects (10), but at least
