gmane.comp.lang.dylan.gwydion.devel

Gwydion Dylan on MacOS X

Hello,

compiling the subversion trunk of Gwydion Dylan on MacOS X I noticed a
few points that could perhaps be improved:

  - I don't think there is any reason why dynamic libraries should be
    disabled for Darwin targets -- simply adding the same
    link-shared-library-command as for Linux to the platforms.descr
    works fine.

  - Recent versions of the Boehm-Demers-Weiser garbage collector library
    don't contain the symbol GC_quiet any longer. As there is no code
    in the Gwydion Dylan codebase that actually uses it, the definitions
    and exports GC-quiet and GC-quiet-setter could be removed from the
    garbage-collection library without doing any harm. At least they
    should be replaced with do-nothing stubs.

  - I attach a library that implements finalization module missing from
    the Common-Dylan library to this e-mail in the hope that it is
    useful.

cu,
Thomas

--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers

(Continue reading)

headers

Thomas Christian Chust | 12 Nov 16:54

Re: Gwydion Dylan on MacOS X

Thomas Christian Chust wrote:

> [...]
>   - I attach a library that implements finalization module missing from
>     the Common-Dylan library to this e-mail in the hope that it is
>     useful.
> [...]

Hmm, apparently the list doesn't accept attachments. I've uploaded the
archive to

  http://www.chust.org/blob/finalization.tar.gz

cu,
Thomas
--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers

headers

Dustin Voss | 13 Nov 02:29

Re: Gwydion Dylan on MacOS X

Good! When I ported the SQL library over to Gwydion Dylan, I had to  
pull finalization out and use explicit close methods.

If one wanted to reintroduce finalization in that library, one could  
search for "finaliz" in trunk/libs/database/sql-odbc/sql-odbc,  
uncomment the finalization-related code, and delete the close- 
statement and close-database functions.

On Nov 12, 2007, at 7:24 AM, Thomas Christian Chust wrote:

> Hello,
>
> compiling the subversion trunk of Gwydion Dylan on MacOS X I noticed a
> few points that could perhaps be improved:
>
> - I don't think there is any reason why dynamic libraries should be
>  disabled for Darwin targets -- simply adding the same
>  link-shared-library-command as for Linux to the platforms.descr
>  works fine.
>
> - Recent versions of the Boehm-Demers-Weiser garbage collector library
>  don't contain the symbol GC_quiet any longer. As there is no code
>  in the Gwydion Dylan codebase that actually uses it, the definitions
>  and exports GC-quiet and GC-quiet-setter could be removed from the
>  garbage-collection library without doing any harm. At least they
>  should be replaced with do-nothing stubs.
>
> - I attach a library that implements finalization module missing from
>  the Common-Dylan library to this e-mail in the hope that it is
>  useful.

(Continue reading)

headers

Bruce Hoult | 13 Nov 02:50

Re: Gwydion Dylan on MacOS X

On Nov 13, 2007 2:29 PM, Dustin Voss <d_j_v <at> mac.com> wrote:
> Good! When I ported the SQL library over to Gwydion Dylan, I had to
> pull finalization out and use explicit close methods.

Please be extremely extremely careful with finalization!!!

I am using a modified Boehm with finalization at work and almost every
time someone writes a finalizer we get at least one very hard to find
bug due to race conditions (usually many months later).

Pure finalization that merely calls close() on some OS thing is ok.
The problem comes about when what you actually want is clean up at the
end of the program, in which case finalization is merely a
finite-memory hack that (sometimes) does the cleanup early.  In this
case the finalizer has to also remove the object from some data
structure containing a (non scanned by the GC) list of things to be
cleaned up. Because the design in Boehm is to by default run
finalizers synchronously from inside the garbage collector, *any*
memory allocation call can (and will, one day) run finalizers.  If
you're not incredibly careful in maintaining your cleanup list then
this will eventually cause  corruption when finalizers are run
removing things from that list in the middle of other code adding
things to the list.

You can not solve this problem with locks.

Either the lock is held by another thread in which case the GC blocks
and any other thread that tries to allocate memory deadlocks with it.
Or else the lock is held by the same thread and either (in the case of
simple locks) deadlocks with itself, or (in the case or recursive

(Continue reading)

headers

Thomas Christian Chust | 13 Nov 14:35

Re: Gwydion Dylan on MacOS X

Bruce Hoult wrote:

> [...] Because the design in Boehm is to by default run
> finalizers synchronously from inside the garbage collector, *any*
> memory allocation call can (and will, one day) run finalizers.  If
> you're not incredibly careful in maintaining your cleanup list then
> this will eventually cause  corruption when finalizers are run
> removing things from that list in the middle of other code adding
> things to the list. [...]

Hello,

as far as I can see, there are two solutions to this problem:

  1) Create a list yourself which you update from the registered
     finalization functions with some mechanism like conditional-update!
     (as you said, locking data structures is not an option) and drain
     this list from a separate thread or from some kind of program main
     event loop -- this is what OpenDylan does, because the interface
     for the runtime is then uniform no matter whether MPS or the
     Boehm-Demers-Weiser collector are used.

  2) Set GC_finalize_on_demand = 1 and let the Boehm-Demers-Weiser
     collector maintain the finalization list for you. Then call
     GC_run_finalizers from a separate thread or from some kind of
     program main event loop to drain the list -- this is what my
     little library does.

Of course the automatic finalization thread cannot be enabled in single
threaded Dylan, so you have to call drain-finalization-queue manually

(Continue reading)

headers

Bruce Hoult | 13 Nov 22:13

Re: Gwydion Dylan on MacOS X

On Nov 14, 2007 2:35 AM, Thomas Christian Chust <chust <at> web.de> wrote:
> Bruce Hoult wrote:
>   2) Set GC_finalize_on_demand = 1 and let the Boehm-Demers-Weiser
>      collector maintain the finalization list for you. Then call
>      GC_run_finalizers from a separate thread or from some kind of
>      program main event loop to drain the list -- this is what my
>      little library does.
>
> Of course the automatic finalization thread cannot be enabled in single
> threaded Dylan, so you have to call drain-finalization-queue manually
> somewhere in your program -- presumably from the main loop of a GUI
> application or in the initialization method of certain objects.

OK, that's reasonable if you don't mind the user having to explicitly
modify their program to do it, and also the possibility of things not
being finalized terribly promptly and, perhaps, expand the heap a lot
if there is code that allocates finalizable objects in a loop and does
not return for a long time.
--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers