Re: state of the Lua nation on resource cleanup

[Mark Hamburg <mark@...>]

With regard to explicit scope management, I believe that Adobe went  
this direction in the Lightroom SDK.

An interesting point of comparison are autorelease pools in Cocoa. The  
short summary is that Cocoa maintains a per thread stack of pools of  
object in need of a release call. (This turns out to make reference  
counting a lot easier to work with since you can return a value with a  
pending reference count decrement.) When you create a new pool, it  
chains onto the existing pool (if any) for the current stack. When you  
destroy a pool, it releases any pools chained below it. Most code can  
get away with a single pool at the top level for processing a command.  
If you need more prompt clean up or you allocate a lot of objects in a  
loop, more localized pools are useful. The key point that makes them  
work well from an API standpoint, however, is that one finds the  
current pool by looking for a thread local variable rather than  
needing to pass it in everywhere.

Given coroutines, I'm not sure what the definition of thread local  
would be since really what we are looking for is call chain local, but  
conceivably we could provide a way to hide the scope managers from  
most of the code while still making their services available. (A  
general notion of call stack controlled dynamic variables would be  
interesting for all of the usual reasons why dynamic variables are  
interesting.)

Mark