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 E7ADF7EE51 for ; Thu, 11 Apr 2013 01:37:52 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAJv2ZVEmacjlnGdsb2JhbABQgzyvLZIXgQUeDgEBAQEBBg0JCRQogh8BAQUnGQEBLAsBDwsLDQ0hIQESAQUBChIGExKHcAMPAwmgV4pvhDsBBYU/AwqJVwaMQ4JTB4NBlSCBY4EhilGDOhYphEo X-IPAS-Result: ApEBAJv2ZVEmacjlnGdsb2JhbABQgzyvLZIXgQUeDgEBAQEBBg0JCRQogh8BAQUnGQEBLAsBDwsLDQ0hIQESAQUBChIGExKHcAMPAwmgV4pvhDsBBYU/AwqJVwaMQ4JTB4NBlSCBY4EhilGDOhYphEo X-IronPort-AV: E=Sophos;i="4.87,450,1363129200"; d="scan'208";a="12729595" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2013 01:37:52 +0200 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1UQ4aN-0001qU-2N for caml-list@inria.fr; Wed, 10 Apr 2013 19:37:51 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UQ4aN-00082w-1Z for caml-list@inria.fr; Wed, 10 Apr 2013 19:37:51 -0400 Received: from mail-bk0-f72.google.com ([209.85.214.72]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1UQ4aM-0000Jn-Th for caml-list@inria.fr; Wed, 10 Apr 2013 19:37:51 -0400 Received: by mail-bk0-f72.google.com with SMTP id q16so1133757bkw.7 for ; Wed, 10 Apr 2013 16:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JLe1RyhS+RugBv0HxGWtOPHjkKC3XEBNPIUkX5ek2Es=; b=s89+k3o6EB47iGIgTIOdUEQgYh8xt4sB2xeVM4Ej/tf8DNH29LFw460xLHY098V+47 mq0ukdtOitYgdooSVojwJzE14qhdVkvHl/SCWjKr+/S9vLURI7PMRYf/xHUZZAqgvQAV 60IYesziTn2zfnETJHd+eR7Aw2IBo+OQp1Y/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JLe1RyhS+RugBv0HxGWtOPHjkKC3XEBNPIUkX5ek2Es=; b=hfEiAyHftu/KCzGblKMf8XS9J9TiM6yBA1Ju/+gK5nNT+AhAUO4FgWjOkIsIZoImKO Hbh/vZnggvfXFtTr9LvRggbtxnq7QlvON0j2PkqsQ9sudTK+0XOaHdKnjRS7IlmSbDH0 nF46NgsSMrVWE8rK7WT8vIl8e2AUkWL6Eygie2v26jh9rtfpxCA8AKd4fMgH4Qoh20Kh XAw9dfmqW79ZTBJrn4EuC6mnzTt9P4M+V0qzblGrnJb7Ywhd7AK/jAstyc5u+Xdxk2mE QBfMu5ufmvHEBCoFQnvh6LfUHwIIkOfoFYhYlabnPym0p33QrrrnJ4o9slyvE0SRcmQr CZtA== X-Received: by 10.14.181.196 with SMTP id l44mr3196905eem.44.1365637070248; Wed, 10 Apr 2013 16:37:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.181.196 with SMTP id l44mr3196885eem.44.1365637070097; Wed, 10 Apr 2013 16:37:50 -0700 (PDT) Received: by 10.223.85.155 with HTTP; Wed, 10 Apr 2013 16:37:49 -0700 (PDT) In-Reply-To: References: <4989654.hHte10Um7f@groupon> Date: Wed, 10 Apr 2013 19:37:49 -0400 Message-ID: From: Yaron Minsky To: Chet Murthy Cc: Caml List Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQme3nOSSTiWggKfo62EidcFbzU/r5UwgzjH6oL7RFGtU7l/vxE0qRJ57+wIc27wLwsI+xuV+LCk+S6p50P/WVKdHhKcMFPsEwvfCHs8q1nbur7DbR84dhVUXl1DBn/lvi91cVT1jUldFYyMICCBojgUtVRx9w== Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml Oh, and as for the thread part of your point, I would strongly recommend using a monadic concurrency library like Async or Lwt rather than coding with system threads in OCaml. It does kill your stack-traces (stack-traces and monadic libraries don't work so well together), but it's totally worth the trade-off. Certainly your deadlock and race-condition problems get a hell of a lot better. y On Wed, Apr 10, 2013 at 7:35 PM, Yaron Minsky wrote: > Chet, are you sure that one looses the stack trace in this case? My > example using Core seems to preserve it. Here's the code: > > open Core.Std > > let a () = let _ = "a" in raise Not_found > let b () = let _ = "b" in a () > > let c () = > let _ = "c" in > protect ~f:b > ~finally:(fun () -> ()) > > let d () = let _ = "d" in c () > let () = d () > > And here's the native code stack-trace: > > $ ./z.native > Fatal error: exception Not_found > Raised at file "z.ml", line 3, characters 32-41 > Called from file "lib/exn.ml", line 63, characters 8-11 > Re-raised at file "lib/exn.ml", line 66, characters 12-15 > Called from file "z.ml", line 11, characters 26-30 > > Here's the code for protect, which is a little different than your > finally, but not by a lot. Maybe the biggest difference is that we > have a special exception (Finally) which we use when the finally > clause throws an exception from an exception handler, so we can > deliver both the exception tha triggered the [finally] and the > exception thrown by the [finally]. > > This is from the Exn module in Core. > > let protectx ~f x ~(finally : _ -> unit) = > let res = > try f x > with exn -> > (try finally x with final_exn -> raise (Finally (exn, final_exn))); > raise exn > in > finally x; > res > ;; > > let protect ~f ~finally = protectx ~f () ~finally > > > On Wed, Apr 10, 2013 at 6:16 PM, 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-- >> >> >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs