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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 20D3A7EE51 for ; Thu, 11 Apr 2013 00:17:08 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of murthy.chet@gmail.com) identity=pra; client-ip=209.85.210.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of murthy.chet@gmail.com designates 209.85.210.177 as permitted sender) identity=mailfrom; client-ip=209.85.210.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="murthy.chet@gmail.com"; 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@mail-ia0-f177.google.com) identity=helo; client-ip=209.85.210.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="murthy.chet@gmail.com"; x-sender="postmaster@mail-ia0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FALrjZVHRVdKxlWdsb2JhbABQiRa8eBYOAQEBAQcNCQkSKoJNEwYBGx4DEiYVHwETEQEFASKIFAEDD51rgnKML4J7hHsKGScNWYh+AQUMklIDiQKdKj+ETg X-IPAS-Result: Ao4FALrjZVHRVdKxlWdsb2JhbABQiRa8eBYOAQEBAQcNCQkSKoJNEwYBGx4DEiYVHwETEQEFASKIFAEDD51rgnKML4J7hHsKGScNWYh+AQUMklIDiQKdKj+ETg X-IronPort-AV: E=Sophos;i="4.87,450,1363129200"; d="scan'208";a="12724365" Received: from mail-ia0-f177.google.com ([209.85.210.177]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Apr 2013 00:17:07 +0200 Received: by mail-ia0-f177.google.com with SMTP id w33so862597iag.22 for ; Wed, 10 Apr 2013 15:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=8mj2pDHkmGuhvKnt8eTZiV4DxbAJ8rkS00unjrB97Oo=; b=FclNpbRioPPfCZNfPqG2S/S8WtJceM96NX8pBh2NuHw5idDwDM6e0c1BexFyJW1vOE 6BDHYXUIruOqC4JxbidlQY+H8UiGIqrlInmKDJu0srKvAEAyavb4seX6J3f2zv11P/LD 2pimRVdkNvWvcIbwa8Uj6sMjV0QpqYeM8bJMvUPrYb9fsOBRlruCgzAKjsAPd8mUdDgq fKDG0EwfNPThP/VrRS1aIEJS6Wcv8+WD797h/YJz5fblk5lPlgw98dSlzln+cFI3g0eW +GH+m/12Ppeq0H/W2oNsjzG/1oAVkg+65QtGs/ANZBnPFXMGIotpvzd8C1Wl0a72OXiF enIA== X-Received: by 10.50.138.198 with SMTP id qs6mr2803775igb.48.1365632226215; Wed, 10 Apr 2013 15:17:06 -0700 (PDT) Received: from groupon.localnet (adsl-76-254-28-19.dsl.pltn13.sbcglobal.net. [76.254.28.19]) by mx.google.com with ESMTPS id xc3sm29200014igb.10.2013.04.10.15.17.04 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 15:17:05 -0700 (PDT) From: Chet Murthy To: Caml List Date: Wed, 10 Apr 2013 15:16:55 -0700 Message-ID: <4989654.hHte10Um7f@groupon> User-Agent: KMail/4.8.5 (Linux/3.2.0-38-generic-pae; KDE/4.8.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml 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--