[Gd-hackers] Suggested patch for Open Dylan's C runtime
Thomas Christian Chust
chust at web.de
Mon Jul 30 16:36:28 CEST 2007
Bruce Hoult wrote:
> [...]
> You could allocate the list link for the object at the point that you
> register the finalizer for it (possibly as part of the object itself
> if you have control over that by, for example, allocating an extra 4
> bytes and lying to the rest of Dylan about where the object starts).
Hello,
I've attached a new patch replacing the other one which implements the
finalization queue as a dynamically sized array with resizing operations
taking place only as necessary in primitive_mps_finalize and
primitive_mps_finalization_queue_first. It seems to work just as well as
the first patch on my machine and I hope it is safer :-)
> In fact if you want to guaranteed that finalizers will be run before
> program exit then you have to do that anyway. Then you'll have the
> actual finalizer remove the object from the program exit cleanup list.
The way finalization is implemented in Open Dylan, finalizers are not
guaranteed to be run on program exit, I think.
> You can also use the facility in Boehm for asynchronous finalization
> using the GC_invoke_finalizers() function and either setting your own
> function into the GC_finalizer_notifier variable or else polling
> GC_should_invoke_finalizers(). So you can for example set
> GC_finalizer_notifier to point to a function that clears a semaphore
> that releases a thread that calls GC_invoke_finalizers(). No need to
> keep track of anything else yourself. The GC won't delete the objects
> until after GC_invoke_finalizers() has been called, even if there is
> another GC in the meantime.
> [...]
That would be possible, but I don't want to rely on multithreading in a
piece of code that should be maximally portable. (Although I think the
idea to use a finalization thread as a coroutine replacing the stored
queue is quite elegant.)
But something different came to my mind when working on this problem:
Wouldn't it be a good idea to implement the CONDITIONAL_UPDATE macro of
Open Dylan's C runtime in a more threadsafe way? I'm thinking of
something that uses the lock instruction prefix on the i386 or the lwarx
/ stwcx. instructions on the PowerPC to achieve real atomicity.
cu,
Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opendylan-finalization.patch
Url: http://www.opendylan.org/pipermail/hackers/attachments/20070730/39791f7f/attachment-0001.txt
More information about the hackers
mailing list