[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