From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 02B547EE51 for ; Thu, 11 Apr 2013 00:29:28 +0200 (CEST) Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=fE0/=N5=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=fE0/=N5=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=fE0/=N5=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=fE0/=N5=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=fE0/=N5=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMBAF/nZVGBaB4inGdsb2JhbABQgzyDK74ZgQ0WDgEBAQEBCAsJCRQogh8BAQUjBGILGAICBRYLAgIJAwIBAgFFEwgBAReHeQQIrDSSeIEjjUBQghiBEwOTNYRshGKOGA X-IPAS-Result: AqMBAF/nZVGBaB4inGdsb2JhbABQgzyDK74ZgQ0WDgEBAQEBCAsJCRQogh8BAQUjBGILGAICBRYLAgIJAwIBAgFFEwgBAReHeQQIrDSSeIEjjUBQghiBEwOTNYRshGKOGA X-IronPort-AV: E=Sophos;i="4.87,450,1363129200"; d="scan'208";a="10526014" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 11 Apr 2013 00:29:03 +0200 Received: from [192.168.0.27] (mna75-4-82-225-76-110.fbx.proxad.net [82.225.76.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 4EC46140C50D9 for ; Thu, 11 Apr 2013 00:29:00 +0200 (CEST) Message-ID: <5165E7AB.8040703@m4x.org> Date: Thu, 11 Apr 2013 00:28:59 +0200 From: simon cruanes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: caml-list@inria.fr References: <4989654.hHte10Um7f@groupon> In-Reply-To: <4989654.hHte10Um7f@groupon> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Apr 11 00:29:00 2013 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000001, queueID=8DC78140C50E0 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml An interesting solution for the safe resource acquisition/release, I believe, is the Go statement "defer" [1]. In OCaml, you would write something like: let my_fun () = Mutex.lock some_lock; defer (fun () -> Mutex.unlock some_lock); (* critical section to the end of the block *) .... let final_result = 42 in final_result (* returns, but runs defer-ed statements first *) In case an exception is thrown before the function returns, defer-ed statements would still be executed, before the exception is raised again (with the full stacktrace). Defer-ed statements are executed in the reverse order of their definitions. It also works for resources like files, sockets, etc. Simon [1] http://blog.golang.org/2010/08/defer-panic-and-recover.html On 11/04/2013 00:16, Chet Murthy wrote: > > People have previously asked about try...finally support in Ocaml, and > it's been observed (correctly) that you can write a little combinator > to give you this support, e.g. > > let finally f arg finf = > let rv = try Inl(f arg) with e -> > Inr e > in (try finf arg rv with e -> ()); > match rv with > Inl v -> v > | Inr e -> raise e > > The problem is, you discard stack-traceback when you rethrow the > exception. One can program around this explicitly by capturing the > backtrace string and appending it to the rethrown exception, but it's > cumbersome and won't work for exceptions like Not_found that are > already defined without a mutable string slot. > > It sure would be nice of ocaml had try...finally that preserved the > traceback information properly .... though maybe it isn't possible. > Certainly in the case where the finally block doesn't raise any > exceptions itself (even those that are caught silently), it seems like > it ought to be possible. > > In an unrelated but similar sense, when programming with threads in > ocaml, it's easy (easy!) to deadlock your program. Now, I've been > writing Java programs for years, and so am aware of how careful one > must be, and I'm writing my code using a single mutex protecting the > critical section. But I forgot and didn't mutex-protect one method -- > what merely printed out the contents of a shared daa-structure, and > when that printout coincided with a thread actually mutating the > data-structure, I got a deadlock. Not hard to track down, and I > chided myself for being lax. > > But the thing is, in Java (blecch!) I would have been able to use the > "javacore" facility to get a full-thread stack-traceback, and could > have used that to get a good idea of where my deadlock was. > > I'm not saying that this is something ocaml should have, but I figured > I'd ask: are others (who use threads in ocaml) wishing for something > like this? > > --chet-- > > >