caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <brian.hurt@qlogic.com>
To: Blair Zajac <blair@orcaware.com>
Cc: Caml Users Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Resource acquisition is initialization
Date: Wed, 11 Dec 2002 13:55:10 -0600 (CST)	[thread overview]
Message-ID: <Pine.LNX.4.33.0212111337130.2036-100000@eagle.ancor.com> (raw)
In-Reply-To: <3DF78FB5.A1642B8@orcaware.com>

On Wed, 11 Dec 2002, Blair Zajac wrote:

> One of the nice things about C++ and Java is that with properly
> designed classes, you don't need to worry about freeing resources
> in complicated code, because the when the objects go out of scope
> either normally or via an exception, they will clean themselves up.
> 
> Here's a good description of this idiom:
> 
> http://sourceforge.net/docman/display_doc.php?docid=8673&group_id=9028

I didn't think you could allocate objects on the stack in Java 
(fundamental types, like ints and booleans, yes- but not objects).

There are three problems I have with this idea.  The first problem is that
it greatly complicates exception handling, as now the exceptions have to
call destructors for all the objects on the stack as they pop the stack
frames off.  The second problem I have with this is what happens when an
object goes out of scope in it's original context, but isn't yet garbage?  
We've all seen C code like:

char * foo(...) {
    char buf[];
    /* do something to fill buf */
    return buf;
}

This sounds like a wonderful way to introduce dangling pointer bugs in the 
language.

Third, I question how usefull this idea is.  OK, so the resource doesn't 
get cleaned up the nanosecond it becomes garbage.  In most cases, this 
isn't a problem- for example, file handlers.  The fact that you have a 
couple of extra, garbage, filehandles open and not yet collected won't 
really hurt much of anything, so long as they get collected (and closed) 
eventually.  Most file objects come with an explicit close option, so even 
if you, for some unknown reason, write code that just sits in a tight loop 
opening files, you can close them just as fast and not leave lots of spare 
file descriptors open.  And Java provides a function to force a garbage 
collection, I beleive Ocaml does as well (in pervasives?  I'm still 
learning the language).

The only thing I can think of which cannot tolerate the cleanup slop is 
releasing a mutex.  Deleting the mutex itself is a good application for 
GC, unlocking the mutex is not.  And for that, I think representing 
holding the lock as the lifetime of an object to be a bad idea.  Were Caml 
interested more in doing multithreaded code, I'd recommend something like 
Java's synchronize keyword.

Brian

-------------------
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


  reply	other threads:[~2002-12-11 19:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-11 19:19 Blair Zajac
2002-12-11 19:55 ` Brian Hurt [this message]
2002-12-12  0:27   ` Chet Murthy
2002-12-12  7:56   ` Alessandro Baretta
2002-12-12 16:39     ` Brian Hurt
2002-12-13  9:22   ` Mike Potanin
2002-12-13 17:05     ` David Brown
2002-12-12 13:15 ` Xavier Leroy
2002-12-12 14:05   ` Dmitry Bely
2002-12-12 14:16     ` Xavier Leroy
2002-12-12 22:17   ` Quetzalcoatl Bradley
2002-12-12 23:59   ` Blair Zajac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.33.0212111337130.2036-100000@eagle.ancor.com \
    --to=brian.hurt@qlogic.com \
    --cc=blair@orcaware.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).