From: Jacques-Henri Jourdan <jacques-henri.jourdan@ens.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml
Date: Thu, 11 Apr 2013 08:25:14 +0200 [thread overview]
Message-ID: <5166574A.5010702@ens.fr> (raw)
In-Reply-To: <4989654.hHte10Um7f@groupon>
[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]
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/
--
JH Jourdan
Le 11/04/2013 00:16, Chet Murthy a écrit :
>
> 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--
>
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
prev parent reply other threads:[~2013-04-11 6:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 22:16 Chet Murthy
2013-04-10 22:28 ` simon cruanes
2013-04-11 0:19 ` Francois Berenger
2013-04-10 23:35 ` Yaron Minsky
2013-04-10 23:37 ` Yaron Minsky
2013-04-11 6:36 ` Malcolm Matalka
2013-04-11 6:42 ` Chet Murthy
2013-04-11 7:11 ` Francois Berenger
2013-04-11 7:17 ` Chet Murthy
2013-04-11 8:04 ` Roberto Di Cosmo
2013-04-11 8:48 ` Malcolm Matalka
2013-04-11 16:43 ` Chet Murthy
2013-04-11 11:13 ` Thomas Gazagnaire
2013-04-11 6:25 ` Jacques-Henri Jourdan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5166574A.5010702@ens.fr \
--to=jacques-henri.jourdan@ens.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox