From: Nat Pryce <nat.pryce@...13media.com>
Date: 2001-11-24T12:31:04+09:00
Subject: [ruby-talk:26289] Re: Ruby GC Determinism [Was: KDE or GNOME curiosity question...]

From: "Phlip" <phlip_cpp@yahoo.com>
> I haven't gotten this far in Ruby, but I understand that in Python
> '__del__' might never call, this means you can't put anything useful in it
> (such as code to change the mouse pointer from a temporary icon back into
> an arrow).
>
> That's what RAII means; it means your local variables' lifespans should
> track your system state.
>
> So consider this pseudo Ruby:
>
>   aConcept = Concept.new
>   begin
>      doStuffThatMightRaise (aConcept)
>   ensure
>      aConcept.changeMouse(Arrow)
>   end
>
> In this code, we are forced to know that Concept has side-effects, and
that
> these must be rolled-back before the current function exits. This means we
> must couple the calling code to what the called code needs, and its
> interface is not as narrow as it could be. We called no method on aConcept
> that change the mouse pointer away from an arrow, but we must still change
> it back reliably.
>
> This is the style that Java coders take for granted & expect.
>
> I'm not knocking 'ensure' (it's a pain to add in C++, for example). But in
> Ruby if a destructor rolled state back, would it deterministically call
> right when aConcept clears its last scope barrier? or is the above code
> required?

No, a finalizer runs *after* the object has been garbage collected.  The
system chooses when to run the garbage collector.  If you want to execute
cleanup code at then end of a scope, use a begin...ensure block.

An alternative Ruby idiom is for a class to provide a method that takes a
block, create a new object, pass it to the block, and clean up the object
once the block has returned.  E.g. the File.open method is used in this way.

Cheers,
            Nat.