Warp wrote:
>   I don't know how it is today, 

Usually a thousand or so, where such things are actually limited by 
something other than the amount of memory available.

>   If a program is constantly opening files, doing something to them, and
> then closing them, a file handle leak (which would happen if it fails to
> close them for some reason, eg. because of a bug or a suprising exception)
> can cause the program to malfunction. And this might not be caught on
> testing, if the testing fails to stress the program in the same way as
> it happens in actual usage...

Yep. That's exactly what was happening to me in my Tcl code. When I 
could get the socket connection but it failed before it finished 
flushing the first buffer, I failed to close the socket. After a couple 
weeks of running, the program would bomb out with a file handle leak. 
That was very annoying to debug. I probably should have just tossed that 
whole function and started over.

>   OTOH, I could imagine that if Java detects that a file cannot be opened
> because of too many file handles being open, it could automatically try
> to run the GC and then try again.

It could. That's what I like to recommend, but oddly few language 
designers listen to me. >8)

>   OTOH, file handles are just *one* possible resource which can leak.
> Java can't be prepared for all of them.

Well, it knows when something fails due to a lack of resources. It's 
even not unreasonable that (for example) opening a file could fail from 
lack of memory to put the stdio buffer in, or something, in which case a 
GC and a retry could correct it.

>> And it might not run if you exit 
>> the program before the GC runs, but that's true of C++ also.
> 
>   It's true of C++ only if your stream has been allocated dynamically
> (directly or indirectly). If it's stack-allocated then there's no way
> its destructor won't be called.

Yeah. And a sufficiently smart compiler for Java or whatever could do 
escape analysis, see that the stream isn't used outside the function, 
and stack allocate it and explicitly clean it up afterwards. Not that 
compilers quite do that yet.

>   (Ok, there is a way: If you call abort() the program is immediately
> terminated without any stack unwinding, in which case no destructors
> are called at all. However, abort() is such a harsh way of terminating
> the program that it shouldn't happen in normal code.

That's what I was talking about, yes. I thought Andrew was referring to 
exiting Haskell with a core dump, basically, rather than simply an 
exception caught at the top level.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message