Hi, Giles

I must relunctantly admit that I did not get your question. Are you asking about GC in general or how GC.start operates in particular? Assuming the latter, here's my rather naż×e take on it. 

Garbage collection is pretty complex facility that works deep inside a VM or an interpreter, governed by its own rules and conditions. So from where you call GC.start it may not even be possible at all to invoke all needed machinery. Rather it is like saying to the VM/interprepter: start garbage collection at you EARLIEST convenience, screw everything regarding optimization and any other considerations. This "screw" part is why it is usually a bad practice to causually intrude into GC realm, as it may drastically affect the performance. 

However, sometimes it may be good to have some communication path between your script and GC. I remember using GC.start after some memory intensive operations are ended when I kind of expect that it will be quiet for some time, thus a good opportunity for GC to cleanup. Also, I used it in some test cases in teardown().

Gennady.

> -----Original Message-----
> From: Giles Bowkett [mailto:gilesb / gmail.com] 
> Sent: Monday, April 17, 2006 12:22
> To: ruby-talk ML
> Subject: Re: IO not closed by GC
> 
> I have a question abt this GC stuff, tangential to the 
> challenge itself, so million pardons, but I see this in many 
> languages -- it's always a suggestion rather than a 
> requirement. Is this just to trip up incautious programmers 
> with shallow understanding? Or is it a hook for special cases 
> when you want to override that stuff w/custom memory mgmt? 
> What's the benefit? I've seen so much use of this type of 
> command in bad Java and virtually never seen ppl using it 
> anywhere else. I guess I sound kind of aggressive or critical 
> but it's a common decision among language designers so there 
> must be some reason for it.
> (Also apologies for the brevity, I'm on my mobile.)
> 
> 
> Giles
> 
> 
> 
> 
> On 4/17/06, Gennady Bystritsky <Gennady.Bystritsky / quest.com> wrote:
> > Even GC.start does not guarantee that the garbage 
> collection will be 
> > actually started, it is just a hint after all. And I am not 
> sure that 
> > even when an IO object is being garbage collected, there will be an 
> > implicit call to close(). I personally would not expect it as no 
> > finalizers are installed by default.
> >
> > So the programmer must take care to write the correct code, 
> short or 
> > long ;-).
> >
> > Even if GC.start helped in your case, the overall code 
> would be longer 
> > (because of calls to GC.start) and work much worse (as GC 
> does a lot 
> > that you may not need for the moment) than what I have 
> suggested. And 
> > using blocks with popen is GUARANTEED to close descriptors 
> properly. 
> > See my point?
> >
> > By the way, you are welcome.
> >
> > Gennady.
> >
> > > -----Original Message-----
> > > From: Stephan Maka [mailto:stephan / spaceboyz.net]
> > > Sent: Monday, April 17, 2006 10:37
> > > To: ruby-talk ML
> > > Subject: Re: IO not closed by GC
> > >
> > > Gennady Bystritsky wrote:
> > > > But you do not even know when GC will be run, so in your
> > > case it might
> > >
> > > Inserting 'GC.start; sleep 1' won't help...
> > >
> > > > not even have kicked in. On the other hand, IO.popen has a
> > > nice block
> > > > form that gurantees that an underlying IO object will be closed 
> > > > properly. You can rewrite your code as:
> > > >
> > > > os = IO.popen('uname -sr') { |io| io.readlines.to_s.strip }
> > >
> > > That works, but is longer. Shorter code is more readable 
> in general...
> > >
> > > Anyway, I think an IO object should be closed when not 
> being needed 
> > > anylonger.
> > >
> > >
> > > Stephan.
> > >
> >
> >
> 
> 
> --
> Giles Bowkett
> http://www.gilesgoatboy.org
> 
>