From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA22093 for caml-redistribution; Mon, 30 Aug 1999 15:49:45 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA31796 for ; Sat, 28 Aug 1999 22:49:43 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA15798 for ; Sat, 28 Aug 1999 22:49:41 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id WAA13305; Sat, 28 Aug 1999 22:49:30 +0200 (MET DST) From: Markus Mottl Message-Id: <199908282049.WAA13305@miss.wu-wien.ac.at> Subject: Re: GC with finalisation? To: Basile.Starynkevitch@cea.fr (STARYNKEVITCH Basile) Date: Sat, 28 Aug 1999 22:49:30 +0100 (MET DST) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <14278.15024.193052.853437@gargle.gargle.HOWL> from "STARYNKEVITCH Basile" at Aug 27, 99 09:13:52 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis > On the other hand, I consider that finalized objects supported by the > language (such as provided by Java & Python) are a mistake. In my > opinion, finalized objects should not have a user-provided finalizer, > but should only deal with system resources (file descriptors, X11 > windows, coded only in C) I once asked for finalizers (for objects) in this list, but I was pointed to problems which I hadn't thought about: for example, user defined finalizers might place the object to be reclaimed in a (global) reference again - what is the garbage collector supposed to do in such cases? Other kinds of side effects (eg. calling methods of other objects) could lead to similar problems. Another argument against finalization is the following: if your program enters a very time-consuming loop in which it doesn't allocate anything, the garbage collector will not be called and the finalization of values/objects might be delayed for a long time. Actually, this is even a problem in languages with stack allocated values: as long as the value is not out of scope, the destructor will not be called (unless the compiler manages to see that the object can be safely finalized and deallocated earlier - which is probably more than tough). Concurrent environments (eg. when doing network communication) may be adversly effected by such delays. Developers of libraries have no control about this, because this problem depends on the way the programmer makes use of values/objects. There are other means to "finalize" values: instead of using destructors/finalizers, you could provide for higher-order functions that do the job. Eg. you want that a network connection is opened, used in some way and closed again (but immediately!). This could look as follows: let do_connection f = let con = open_connection (...) in f con; close_connection con If you provide only such functions to the user, he doesn't have to care about closing connections or do some other finalization and he still has the guarantee that connections are closed immediately - which might allow the server on the other side of the connection to do something more useful than wait... Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl