Detecting at runtime when bindings go out of scope?

[David McClain]

I have been reworking my Reppy Channels for the past week or so. Then I ran into this article from yore…

http://erikdemaine.org/papers/CCC97/paper.ps <http://erikdemaine.org/papers/CCC97/paper.ps>

The article prompted me to wonder about Lisp bindings. We all know how to write a macro to protect and discard resources, e.g., 

(defmacro with-channel (ch &body body)
	`(let ((,ch  (make-channel)))
		(unwind-protect
			(progn
				, at body)
		(discard-channel ch))))

And that works just fine. At the end of use for the ephemeral channel, we discard it, and hence scavenge up any threads that might have been waiting on it. Threads are a relatively precious system resource, and so scavenging is a useful thing to do. They won’t ever be garbage collected because, typically, the Lisp system keeps a list of running threads. Hence there will always be outstanding, if useless, references to them.

But then I began wondering if there could be a way to automatically detect when a resource goes out of scope / context? Why should we have to write the WITH- macros? Memory is automatically reclaimed. Why couldn’t we have a method that could also automatically reclaims vital system resources?

Of course if the channel were ever handed off to another thread and stored away somewhere, it shouldn’t be reclaimed. But I already have GC finalization to help with that case.

What I’m wondering about is being able to declare an item, a special kind of Constructor parameter, which refers to a system resource that needs scavenging, such that I could forego the WITH- formalism? Maybe I’m asking for too much here… how would we ever detect the item being stored? We’d need reference counting, and I tend to dislike that approach very much..

Anyone ever seen a system for resource reclamation that is better than WITH- and UNWIND-PROTECT?

- DM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20160825/d8f4bb63/attachment.html>