From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA22036; Mon, 17 Nov 2003 20:16:08 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA22582 for ; Mon, 17 Nov 2003 20:15:46 +0100 (MET) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hAHJFh112527 for ; Mon, 17 Nov 2003 20:15:44 +0100 (MET) Received: from 203-219-234-160-syd-ts25-2600.tpgi.com.au (203-219-234-160-syd-ts25-2600.tpgi.com.au [203.219.234.160]) by mail2.tpgi.com.au (8.12.10/8.12.10) with ESMTP id hAHJFb1I008442; Tue, 18 Nov 2003 06:15:38 +1100 Subject: Re: [Caml-list] GC and file descriptors From: skaller Reply-To: skaller@ozemail.com.au To: Brian Hurt Cc: Caml Mailing List In-Reply-To: References: Content-Type: text/plain Message-Id: <1069092899.17437.58.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 18 Nov 2003 05:15:00 +1100 Content-Transfer-Encoding: 7bit X-Kaspersky-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 era:99 bagley:01 java's:01 downcasting:01 everthing:01 python:01 interscript:01 orderly:01 finalization:01 finalisers:01 interscript:01 dependencies:01 guarenteed:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2003-11-17 at 06:19, Brian Hurt wrote: > On 16 Nov 2003, skaller wrote: > I wish the mainstream would crawl out of the sixties era computer science > and get at least into the eighties. Lol, they're up to the sixties already? > The only "mainstream" programming > language I know of with *excusable* garbage collection is Java. I think Ocaml is very close to mainstream now. [And I think the FP contest and Bagley are responsible, and ORiley book in English will be the clincher] Very hard to be the second (and third) fastest programming language around and not be noticed :-) > Of > course, Java's type system is state of the art- for 1968. Err.. since when is downcasting everthing from Object a type system?? > > Because of this problem, my own major Python program > > interscript would not run on my interpreter, since > > it relied on orderly finalisation. > You were abusing finalization. Well no. I was *trying* to abuse it but failed :-) In fact, partly my prompting on this was responsible for Ocaml coded finalisers (instead of just C ones). > A much better way to do this would be to > have a central command queue. This would have been impossible in interscript. It works by executing user commands directly (but in a restricted environment). > > > > Anyhow .. there do exist cases where explicit finalisation > > is difficult. > > IIRC, in the general case it's equivelent to solving the halting problem. If I can make a general comment here: there are things like comparing functions which are equivalent to the halting problem. Another is verifying program correctness :-) But it is irrelevant, because programmers do not intend to write arbitrary code. They intend to write comprehensible code, whose correctness is therefore necessarily easy to prove. This is also true of finalisation. Necessarily. The general case is irrelevant, because people don't intend to write arbitrary code. Even when multiple people work on an Open Source project (just about the worst environment I can think of .. ) there is at least an intent to follow a design. > On a more general note, I will agree that having the GC free non-memory > resources raises problems. I agree (and strongly beleive) that everything > that isn't memory should have some way for the program to free them > without invoking the GC- for example, file descriptors should have a close > routine. And I agree that programs *should* use them instead of relying > on the GC in all but the most intractable cases. If I may modify that: *even* in the most intractible cases :-) However, two things spring to mind. First: if close is a primitive operation, we need a high level way of not only tracking what to close, but also of doing that tracking efficiently. Secondly, since the resource is represented in memory, and much of the time the dependencies which are *not* represented in memory could be, using the code of the garbage collector (and not just the same algorithm), makes some sense. > The question is, is it worse to have the GC try to reclaim the resources > than it is to have a guarenteed leak? You are making an incorrect assumption here. You're assuming that finalisers only release resources. Consider again the case where the final action in generating a document is to create a table of contents (know nnow that all chapters are seen). That is a quite non-trivial task which can take a lot of time and involve a very large amount of code, build new objects, etc. The time to do this operation is "when the user cannot add anymore chapters to the document" and the easiest time to specify that is "when the user no longer has any copy of the document handle". This finalisation task isn't a destructor and it isn't releasing anything, but it is, by specification, a finalisation task. > Consider the case where close > return EINTR and doesn't close the file descriptor. Since the descriptor > has already leaked- for it to reach this point the program no longer has > any way to reach the descriptor (if the program did, the object wouldn't > be being collected). So what's the difference in this case between the > collector silently ignoring the error, and the collector not even trying > to free the resource? Probably none, BUT you have again made an assumption and this time it is a fatal mistake. Closing a file is not usually done to free the resource, but to flush the buffers. In interscript, this proved difficult, because sometimes client code would expect to reopen and read the file after the last reference: unfortunately, the open actually works and reads 90% of the file (the last 10% still in a buffer). I fix that problem by always writing a temporary file, and copying it when the file is closed. So here, the finalisation is vital (it copies a file, as well as closing one). > Actually, an idea I've had is to add Java-style "throws" information- > basically what exceptions a function can throw- to the type information of > a function. With type inference, this shouldn't be the headache in Ocaml > it is in Java. The advantage here is that you could enlist the type > system to gaurentee that a destructor doesn't throw any exceptions- i.e. > the code for a destructor should handle all exceptions it generates. Sigh. I argued strongly in C++ that exception specifications should be statically enforced. They're not. Its a total pain, because they ALMOST are. Unfortunately, if you throw an exception you're not allowed to .. a run time check detects the fault and throw an Unexpected exception. You can rely on it .. and it totally defeats any attempt to do static analysis (that one leak can be turned into a complete defeat of the exception specifications). On thing is for sure .. I *hate* seeing "program terminated with uncaught "Not_found" exception" because I do hundreds of Hashtbl.find calls.... ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners