Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
OCaml 3.11.0 release candidate
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-11-29 (22:47)
From: <forum@x...>
Subject: Re: [Caml-list] OCaml 3.11.0 release candidate

Le 25 nov. 08 à 18:09, Damien Doligez a écrit :

> Dear OCaml users,
> We are closing in on version 3.11.0.  A Release Candidate is now  
> available.
> If there are no show-stoppers in this RC, then 3.11.0 will be  
> officially
> released next week.
> The release candidate is available here:
> < >
> (look for 3.11.0+rc1)
> As usual, we need a few brave souls to try and install it on their
> favourite architecture and report the result to me.

Definitely not a show-stopper but I am quite puzzled by the semantics
of the newly-introduced "Printexc.get_backtrace" function (and hence
also by "Printexc.print_backtrace").

Things are not pleasant to me regarding programs involving multiple  
By using "Printexc.get_backtrace" one may get an exception raised in
another thread. In the following program, there is no guarantee that the
two "print" expressions will output coherent results: the backtrace  
may be the one of an exception thrown by another thread.

   with e ->
     print_endline (Printexc.to_string e);
     print_endline (Printexc.get_backtrace ())

Of course, coherence could be ensured by using a lock/mutex but I find  
solution heavyweight (and even in some cases tricky because of existing
synchronization). Another option (involing changes to the OCaml runtime)
would be to attach each backtrace to either its exception or to its  

Am I wrong ? Is the problem of no practical importance ?
Any comment or correction is very welcome to enlighten me.

Xavier Clerc