Re: [Caml-list] Scoped Bound Resource Management just for C++?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mittwoch, den 09.02.2011, 10:15 -0500 schrieb orbitz@ezabel.com:
> Thanks for the answers everyone.
> 
> How does one safely write code in Ocaml that guarantees resources will  
> be freed?  Guillaume mentioned the with-idiom, but even that doesn't  
> seem entirely safe.

You mean C++ is safer in this respect?

Come on. Fully automatic memory management as in Ocaml is certainly
safer than any semi-automatic scheme. It will find all memory blocks
that are not referenced anymore. It's guaranteed. It works even with
circular structures (this is not a boy GC).

You would use "with" only for cases where non-memory resources are
referenced, like file descriptors. And you have to close files in C++,
too. If you want to be very careful here, you can even set a finaliser
that emits a warning when you forgot to close a descriptor (but you have
then to remember whether you closed it), like in

type managed_fd =
  { fd : Unix.file_descr;
    mutable fd_closed : bool
  }

(* after opening the file: *)
let mfd = { fd=fd; fd_closed=false }

(* Attach the finaliser: *)
let mfd_fin mfd =
  if not mfd.fd_closed then
    prerr_endline "Hey, there is a forgotten file descriptor"
Gc.finalise mfd_fin mfd

(* Use mfd as in - ensure you always pass mfd around: *)
Unix.read mfd.fd ...

(* When you close: *)
Unix.close mfd.fd;
mfd.fd_closed <- true

I wouldn't recommend to close fd in mfd_fin, because fd might not be a
simple file, and you can trigger any kind of external activity by
closing it.

I've written a number of 24/7 server programs in Ocaml now, and I can
tell you, resource management is easy. You can usually skip the "search
for memory leaks" step before deploying to production.

Gerd

> On Feb 9, 2011, at 7:01 AM, rossberg@mpi-sws.org wrote:
> 
> >> One of the benefits, in my opinion, of C++ is SBRM.  You can reason
> >> about the lifetime of an object and have an give yourself guarantees
> >> about its clean up.  The method of initialization and clean up are
> >> also consistent for every object in the language.
> >
> > Don't believe the hype. :) Scope-bound resource management is  
> > inherently
> > broken, at least without sophisticated type system support. In a
> > higher-order language, there are various ways in which objects could  
> > escape
> > their scope, e.g. closures, references, exceptions. That can only  
> > mean one
> > of two things for SBRM:
> >
> > 1) Either it is not actually true, i.e. life times are not actually  
> > bound by
> > scope in general and you have no actual guarantees,
> >
> > 2) or it is unsafe, i.e. you can access an object after its life  
> > time has
> > ended, with potentially desastrous effects.
> >
> > C++ chose (2), which is out of the question for a safe language. If  
> > your
> > language makes heavy use of first-class functions (and thus  
> > closures) that
> > strategy is a particular no-go.
> >
> > Also, SBRM does not scale at all to concurrency. The underlying  
> > assumption
> > that all life times are somehow well-bracketed through the dynamic  
> > calling
> > hierarchy simply doesn't hold anymore when you have shared-state
> > concurrency. Getting life times right in concurrent C++ is a  
> > nightmare in my
> > experience, and often requires synchronizing deallocation in quite
> > inefficient ways (thereby effectively making it explicit, and  
> > subverting the
> > whole idea of tying it to scope implicitly).
> >
> > /Andreas
> >
> 
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------