- trivial-garbage-devel - mailman3.common-lisp.net

Re: Testing if the implementation can support weak pointers
by Luís Oliveira 30 Jul '19

30 Jul '19

OK. I'd like to cover the other features too. How about signalling a tg:unsupported-weak-operation error? Would that work for your use case? This would be similar to the current mode of operation (except we currently signal a generic simple-error). Cheers, Luís On Tue, Jul 30, 2019, 2:12 AM Name Here <theemacsshibe(a)gmail.com> wrote: > Yes, we're trying to factor out the implementation-specific code so that > only trivial-garbage needs to be updated for new implementations with weak > pointers, but we also want Flexichain to mostly work if the implementation > does not support weak pointers, falling back to strong pointers in that > case. >

2 1

Testing if the implementation can support weak pointers
by Name Here 29 Jul '19

29 Jul '19

Hello everyone, I was wondering if there is a way to test if the implementation we are running on can create weak pointers. In the case of Flexichain (and I think this might be a possibility for other libraries) using weak pointers isn't completely required, but it's preferred to avoid leaking memory slowly. Currently Flexichain has its own 15-line function that creates weak pointers, which is very similar to that of trivial-garbage, except that it returns the provided value if it cannot create a weak pointer (after warning the user at load-time). We'd like to replace this with a call to trivial-garbage:make-weak-pointer to avoid duplication, but we also want to fall back to just returning the value as previously mentioned; I could do (or (tg:make-weak-pointer value) value) as it will fall through to returning nil, but that feels icky and then I need to figure out a similar trick for weak-pointer-value. If there isn't such a test, I have written a trivial implementation, simply gathering all the #+ forms to choose a constant to return: https://github.com/nodefunallowed/trivial-garbage/blob/master/trivial-garba… Again, this is probably good for a class of programs that uses weak pointers in a way that isn't strictly necessary but very useful. Thanks very much.

2 1

Re: [trivial-garbage-devel] Finalize with closure
by Luís Oliveira 13 Dec '12

13 Dec '12

On Wed, Dec 12, 2012 at 9:36 PM, Hans Höglund <hans(a)hanshoglund.se> wrote: > I use 32-bit LispWorks on OS X 10.7 and it works well enough. > > I do not know the behavior in other implementations. Right, I re-checked the documentation and Lispworks indeed runs the finalizer before reclaiming the object, which is why your approach works there. It won't work in SBCL, for example. As such, we cannot support this feature in a portable fashion. :-/ I've created a new issue to document this: <https://github.com/trivial-garbage/trivial-garbage/issues/8>. Thanks, -- Luís Oliveira http://r42.eu/~luis/

2 1

[trivial-garbage-devel] Finalize with closure
by Hans Höglund 09 Dec '12

09 Dec '12

Hello, I found myself wanting to reference the finalized object from a finalizer, so I added this wrapper around trivial-garbage:finalize, using a weak pointer to avoid permanently referencing the object from the finalizer closure. (defun add-finalizer (x f) (setf p (make-weak-pointer x)) (setf g (lambda () (funcall f (weak-pointer-value p)))) (finalize x g)) Would there be any problems with adding this function to the main library? I could probably provide a patch if requested. Best regards, Hans

2 1