From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 4659C7EE51 for ; Thu, 11 Apr 2013 08:25:42 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jacques-henri.jourdan@ens.fr) identity=pra; client-ip=176.31.242.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jacques-henri.jourdan@ens.fr"; x-sender="jacques-henri.jourdan@ens.fr"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of jacques-henri.jourdan@ens.fr does not assert whether or not 176.31.242.187 is permitted sender) identity=mailfrom; client-ip=176.31.242.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jacques-henri.jourdan@ens.fr"; x-sender="jacques-henri.jourdan@ens.fr"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@ulminfo.fr) identity=helo; client-ip=176.31.242.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jacques-henri.jourdan@ens.fr"; x-sender="postmaster@ulminfo.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkCACJXZlGwH/K7nGdsb2JhbABQgmVXwUuBAhYOAQEBAQEIFAk8giABBSdREQshFg8JAwIBAgFFEwgBAReHegMIvxWNU4FKFoMrA49RgSmHJ5J6 X-IPAS-Result: AhkCACJXZlGwH/K7nGdsb2JhbABQgmVXwUuBAhYOAQEBAQEIFAk8giABBSdREQshFg8JAwIBAgFFEwgBAReHegMIvxWNU4FKFoMrA49RgSmHJ5J6 X-IronPort-AV: E=Sophos;i="4.87,453,1363129200"; d="asc'?scan'208";a="12754879" Received: from ulminfo.fr ([176.31.242.187]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 11 Apr 2013 08:25:16 +0200 Received: from [IPv6:2a01:e35:8bca:e060:221:6aff:fe6f:b400] (unknown [IPv6:2a01:e35:8bca:e060:221:6aff:fe6f:b400]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ulminfo.fr (Postfix) with ESMTPSA id F084040F69 for ; Thu, 11 Apr 2013 08:25:14 +0200 (CEST) Message-ID: <5166574A.5010702@ens.fr> Date: Thu, 11 Apr 2013 08:25:14 +0200 From: Jacques-Henri Jourdan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DVXNBLKXNCQGPIWWUGVW" Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DVXNBLKXNCQGPIWWUGVW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I recently published a blog post proposing a solution to the backtrace problem of Ocaml. It includes a Camlp4 filter and a small Ocaml library to handle exception backtraces. The performance drawback is negligible when backtraces are not activated, and reasonable when they are. You can read about it here : http://gallium.inria.fr/blog/a-library-to-record-ocaml-backtraces/ --=20 JH Jourdan Le 11/04/2013 00:16, Chet Murthy a =E9crit : >=20 > 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. >=20 > let finally f arg finf =3D > let rv =3D 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > --chet-- >=20 >=20 >=20 ------enig2DVXNBLKXNCQGPIWWUGVW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRZldKAAoJEGHoGlEY1GjFsRwH/Atybn0yv+vIIuhlR50v0q+A STl0zj7ZLUafs/Fmj//ML9iO+SG3G7DM6tCfciNlRczdSbg5MJwOPibG5ePVfAVh kNlnyzQeSQIc5t9xcEcdZQohLORGJFR3F299nOPE9LYoUMLnZgE/8rL8SaMZUudN rjREhGK79SXmbyVqFIV+dHz8s75Y0v+ZYQdHpK3vuYpXc3QsWKd017h6uThTc2Jl w/p08giA13onGHA4VTGsTTZ7WOomJGtABnHSDUsjpbxppmDNBr+gJnVnRK/LyNfj 3A8xe8PXs0x831WjHEja7xBhIMJQMGk3NCJewDrcSzjnm+jmKU5s4eazwZPTDdE= =7ZWH -----END PGP SIGNATURE----- ------enig2DVXNBLKXNCQGPIWWUGVW--