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
next prev parent 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