diff options
Diffstat (limited to 'libguile/finalizers.c')
-rw-r--r-- | libguile/finalizers.c | 43 |
1 files changed, 0 insertions, 43 deletions
diff --git a/libguile/finalizers.c b/libguile/finalizers.c index 36159488f..816e87351 100644 --- a/libguile/finalizers.c +++ b/libguile/finalizers.c @@ -389,49 +389,6 @@ scm_i_finalizer_pre_fork (void) -static void -async_gc_finalizer (void *ptr, void *data) -{ - void **obj = ptr; - void (*callback) (void) = obj[0]; - - callback (); - - scm_i_set_finalizer (ptr, async_gc_finalizer, data); -} - -/* Arrange to call CALLBACK asynchronously after each GC. The callback - will be invoked from a finalizer, which may be from an async or from - another thread. - - As an implementation detail, the way this works is that we allocate a - fresh object and put the callback in the object. We know that this - object should get collected the next time GC is run, so we attach a - finalizer to it to trigger the callback. - - Once the callback runs, we re-attach a finalizer to that fresh object - to prepare for the next GC, and the process repeats indefinitely. - - We could use the scm_after_gc_hook, but using a finalizer has the - advantage of potentially running in another thread, decreasing pause - time. - - Note that libgc currently has a heuristic that adding 500 finalizable - objects will cause GC to collect rather than expand the heap, - drastically reducing performance on workloads that actually need to - expand the heap. Therefore scm_i_register_async_gc_callback is - inappropriate for using on unbounded numbers of callbacks. */ -void -scm_i_register_async_gc_callback (void (*callback) (void)) -{ - void **obj = GC_MALLOC_ATOMIC (sizeof (void*)); - - obj[0] = (void*)callback; - - scm_i_set_finalizer (obj, async_gc_finalizer, NULL); -} - - int scm_set_automatic_finalization_enabled (int enabled_p) { |