# File.open{} , huge files and gc

**URL:** <https://rubytalk.org/t/file-open-huge-files-and-gc/7096>\
**Category:** ruby-talk\
**Created:** [30 July 2003 02:18 UTC](https://rubytalk.org/t/file-open-huge-files-and-gc/7096 "2003-07-30T02:18:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Laurent\_Julliard4](https://avatars.discourse-cdn.com/v4/letter/l/ebca7d/32.png) [@Laurent\_Julliard4](https://rubytalk.org/u/Laurent_Julliard4)\
**Post date:** [30 July 2003 02:18 UTC](https://rubytalk.org/t/file-open-huge-files-and-gc/7096/1 "2003-07-30T02:18:49Z")

</div>

I just came across a diuscussion about C++ smart pointers and Python’s  
refcount GC.  
So I fall in the doubt:

If I call File.open ‘my\_huge\_file’ { |fd|  
…  
}

How should I feel? 🙂  
I mean: would fd be freed or have I to manually start the GC after the  
block?  
actually the question could be: when GC gets called ?

---

<div class="post-metadata">

**Author:** ![Nucleon](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@Nucleon](https://rubytalk.org/u/Nucleon)\
**Post date:** [30 July 2003 02:12 UTC](https://rubytalk.org/t/file-open-huge-files-and-gc/7096/2 "2003-07-30T02:12:38Z")

</div>

The price you pay for not needing to keep track of the ownership and  
deallocation of everything you allocate is that you can’t be certain when  
your object will be deleted. In other words, there’s a constructor, but  
no destructor.

You can force the GC to run, but this is kind of a hack. (I’m not sure if  
you’re guaranteed the GC will finish before GC.start returns.) Also,  
there are destructors, but they’re very hackish and are not encouraged.

In practice, in GC’d languages, objects need to manage their non-memory  
resources (like open file descriptors) differently. In C++ the resources  
are freed when the object is destroyed. In Ruby, it’s typical to make a  
function that allocates, yields, and frees.

So to answer your question, File.open works that way. When you pass it a  
block, File.open closes the file descriptor after the block is finished.  
The fd structure in memory still exists until the GC runs, but as far as  
the operating system is concerned, the file is closed.

> **···**
>
> On Mon, 28 Jul 2003 00:01:36 +0000, gabriele renzi wrote:
> 
> > I just came across a diuscussion about C++ smart pointers and Python’s  
> > refcount GC.  
> > So I fall in the doubt:
> > 
> > If I call File.open ‘my\_huge\_file’ { |fd|  
> > …  
> > }
> > 
> > How should I feel? 🙂  
> > I mean: would fd be freed or have I to manually start the GC after the  
> > block?  
> > actually the question could be: when GC gets called ?
> 
> –  
> Tom Felker
> 
> War not make one great.  
> – Yoda

---

<div class="post-metadata">

**Author:** ![Laurent\_Julliard4](https://avatars.discourse-cdn.com/v4/letter/l/ebca7d/32.png) [@Laurent\_Julliard4](https://rubytalk.org/u/Laurent_Julliard4)\
**Post date:** [30 July 2003 02:17 UTC](https://rubytalk.org/t/file-open-huge-files-and-gc/7096/3 "2003-07-30T02:17:17Z")

</div>

> In practice, in GC’d languages, objects need to manage their non-memory  
> resources (like open file descriptors) differently. In C++ the resources  
> are freed when the object is destroyed. In Ruby, it’s typical to make a  
> function that allocates, yields, and frees.

well, the point is that in refernce count GC I can be sure that fd is  
deleted at the end of the block (yeah, I know that refcount is bad).

> So to answer your question, File.open works that way. When you pass it a  
> block, File.open closes the file descriptor after the block is finished.  
> The fd structure in memory still exists until the GC runs, but as far as  
> the operating system is concerned, the file is closed.

sure, I know, but someone on #ruby-lang pointed me to the idea that  
ruby could understand when I’m using huge temp memory, and someway try  
to chooce if it should free it (i.e. if it malloced lots of stuff in a  
block it could choice to free 'em at the endo of the same block).  
So, is it true?

> **···**
>
> il Mon, 28 Jul 2003 00:15:14 -0500, Tom Felker [tcfelker@mtco.com](mailto:tcfelker@mtco.com) ha scritto::

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [30 July 2003 02:17 UTC](https://rubytalk.org/t/file-open-huge-files-and-gc/7096/4 "2003-07-30T02:17:47Z")

</div>

“gabriele renzi” [surrender\_it@remove.yahoo.it](mailto:surrender_it@remove.yahoo.it) schrieb im Newsbeitrag  
[news:7kp8ivg68h2ktu9gql7d5ofm9m6o7spt27@4ax.com](mailto:news:7kp8ivg68h2ktu9gql7d5ofm9m6o7spt27@4ax.com)…

> I just came across a diuscussion about C++ smart pointers and Python’s  
> refcount GC.  
> So I fall in the doubt:
> 
> If I call File.open ‘my\_huge\_file’ { |fd|  
> …  
> }
> 
> How should I feel? 🙂  
> I mean: would fd be freed or have I to manually start the GC after the  
> block?

I don’t see the problem since fd is just the File instance, i.e. mainly  
the file handle. That doesn’t consume much mem. It especially consumes  
the same amount of mem for every file (at least it’s likely to be bounded  
by a buffer size.)

Or am I wrong?

> actually the question could be: when GC gets called ?

Whenever ruby feels like it or you tell the interpreter. 🙂

```
robert

```
