From: Dennis Newbold <dennisn@...>
Date: 2002-05-11T02:43:33+09:00
Subject: Re: rb_unload() ?

Hi Jeff,

     I don't completely understand what you are trying to do, but it
sounds like you want to subdvide your solution into two or more pieces,
a persistent part, and a temporary part.  Presumably, the temporary
part will do some work, and leave its results in a file, or write them
to a pipe or something, so they will be accessible to the persistent part,
once the temporary part goes away.  A couple of possible solutions
might be:

   1. use the IO#popen method, with a single hyphen as the name of the
      child process.  This will fork a new copy of the Ruby interpreter
      with access to all constants, classes, methods, that have been
      defined up to the point that it was created.  Anything new that
      it creates will disappear when it dies.  However, any writes to
      memory that it does will not affect the parent interpreter, as
      the memory of a forked child process is tagged as copy-on-write.
      Thus, any communication between the child and the parent copies
      of the interpreter must be via the pipe, or via files on disk,
      sockets, or some other form of IPC.

   2. Read the entire script for the temporary part into a Ruby string,
      and then execute in by passing it to rb_eval().  I believe this
      will work, but haven't trie it.  Also, I'm not sure of the context
      it executes in (i.e., whether it can access constants, variables,
      etc. defined in the scope of the calling process.

   3. Define the classes, variables, class instances, etc. that you
      want to be temporary from within a function.  This will limit
      their existence to the scope of that function.  When execution
      leaves the function, the things defined inside it will go out of
      scope, and their memory will be reclaimed by the garbage collector.

The statements I've made here are true to the best of my knowledge, but
I'm not an expert on Ruby semantics or Ruby internals.  If someone else
on the list would like to correct or amend anything I've said here, please
feel free.  We'd all benefit from it.

One final note -- if your desire is to make your project cleaner and
more inderstandable by breaking it into smaller pieces, then that's a
great thing!  If you are concerned about memory usage, I wouldn't worry
too much about it, as its all virtual anyway.  Any memory you haven't used
for awhile will just get moved to the swap file eventaully.  And, if you
are concerned about namespace pollution, and having several classes,
methods, or variables of the same name, you can control that by requiring
the module you need, but not including it.  You can then reference its
methods and variables using the :: scope operator.

Hope this helps.

Dennis

---------------------------------------------
|                                           |
|     The way to be happy is to be good     |
|                                           |
---------------------------------------------

On Fri, 10 May 2002, Jeff Ward wrote:

> I'm experimenting with using ruby as embedded scripting language, but 
> I've run across a problem.  I don't want things to stay resident after 
> I'm finished with a file.  Is there something like rb_unload or rb_flush 
> that won't uninitialize ruby but will remove all defined classes, 
> functions, and variables from memory?  Even better if there's a way to 
> keep constants resident.
>