Re: On timely destruction?

[theorbtwo]

in reply to On timely destruction?

I often have filehandles that escape their lexical context. To whit, I have a sub to open a file, and return the filehandle. It's called replacable parts -- for the prototype I have it open a static filename, later I have it be more configurable, with a config file, or whatever. (OK, I don't, but if I wrote cleanly, I would.)

---

Confession: It does an Immortal Body good.

[Elian]

That's fine--that sort of thing is still perfectly legal and will be handled fine. The question is: Do you depend on the returned filehandle being immediately closed when the variable holding it goes out of scope? If "sooner or later, as long as it's not too much later" is OK (and the later part is on the order of milliseconds, usually), then it's not a problem and not something I need to worry about here.

[theorbtwo]

Well, in the case of most of the scripts I write, no, I don't rely on timely destruction; I rarely deal with high-contention files. However, even with fairly high-contention files (and suchlike things), an unlock being a few ms late shouldn't be to terrible.

---

Confession: It does an Immortal Body good.

[Anonymous Monk]

The main problem that I see is that people may do a lot of suffering from buffering. For instance in a function they write to a file. But they don't have an explicit close, so it doesn't get flushed until gc. Elsewhere you interact with the same file (perhaps you called the same function again) and get all confused when data that you know has been written, hasn't been. (And since you are sure that it has been written - a fact that you can verify by looking at it in an editor - you will look everywhere else for the problem instead...)