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 57D0B7EE51 for ; Thu, 11 Apr 2013 02:19:58 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.162; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.162 as permitted sender) identity=mailfrom; client-ip=134.160.33.162; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.162 as permitted sender) identity=helo; client-ip=134.160.33.162; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMBAF4BZlGGoCGinGdsb2JhbABQgzyDK74ZgSQOAQEBAQEICwkJFCiCHwEBBAEjBBFABgsLGAICBRYLAgIJAwIBAgFFBg0IAQEXh3MGDKw2knaBI41AOoIugRMDiQCKNYNLgSGEYo4l X-IPAS-Result: AoMBAF4BZlGGoCGinGdsb2JhbABQgzyDK74ZgSQOAQEBAQEICwkJFCiCHwEBBAEjBBFABgsLGAICBRYLAgIJAwIBAgFFBg0IAQEXh3MGDKw2knaBI41AOoIugRMDiQCKNYNLgSGEYo4l X-IronPort-AV: E=Sophos;i="4.87,451,1363129200"; d="scan'208";a="10530827" Received: from postman2.riken.jp (HELO postman.riken.jp) ([134.160.33.162]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Apr 2013 02:19:56 +0200 Received: from postman.riken.jp (postman2.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 089A11260515 for ; Thu, 11 Apr 2013 09:19:52 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id A344E127005B for ; Thu, 11 Apr 2013 09:19:51 +0900 (JST) Message-ID: <516601A7.7020103@riken.jp> Date: Thu, 11 Apr 2013 09:19:51 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: caml-list References: <4989654.hHte10Um7f@groupon> <5165E7AB.8040703@m4x.org> In-Reply-To: <5165E7AB.8040703@m4x.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.11.1518 Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml On 04/11/2013 07:28 AM, simon cruanes wrote: > 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. There is at_exit from Pervasives that looks like a defer, but only at the program level unfortunately. I think I read that at Citrix thay garbage-collect everything: open files, acquired locks, etc. I have no idea of how they manage to do this, however. Regards, F. > 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-- >> >> >> > >