On 3/24/07, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> wrote:

> there are two issues here
>
>    - the fd, which __is__ released at the end of the block

Released in the sense that File.open closes the file handle after
execution of the block when a block is given.

>    - any ruby variables, which will only be freed by the GC

I've got to quibble with this.  It's objects which are freed by the
GC, not variables.  The distinction between objects and
variables(references) is subtle, but it also trips up a lot of newbies
which is why I'm going into this.

Ruby variables are simply 'slots' which reference objects.

  Method or block temporaries (pretty much the same thing in 1.8)  and
method parameters exist on the call stack and go away when the call
stack is popped.

  Instance variables  are value slots in a hash table pointed to by an
object.  These variables live as long as the object does, or until
they are removed with remove_instance_variable.

  Class variables and Constants are similarly associated with a Class
or Module object, and Globals are kept in a global registry.

So other than the variables which exist on the call stack, variables
are never automatically freed.

But an object becomes a candidate to be freeded (actually to have its
space reclaimed) by the GC when there are no variables reachable by
following chains of variable references starting with either variables
on the stacks of any threads, or constants (actually constants in the
root namespace)

Also this only makes the object a candidate for GC, there is no
guarantee of how soon, if ever, after all references to an object are
gone that an object will be reclaimed by the GC.  Which is why it's a
bad idea to rely on finalization to clean up external resources
associated with an object.
-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/