Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml

[Chet Murthy <murthy.chet@gmail.com>]

I agree that a monadic style would be nice.  Of course, you'd lose
even -more- of your stack (as it disappears into the
continuation-chain).  In this case, I'm working with code (Thrift)
that relies on threads, and while I could fix it, right now is not the
time.  So threads are an externally-imposed requirement.

Also, I notice that nobody's mentioned any sort of solution to "my
threaded program deadlocked; I'm pretty sure I screwed up my locking
-- how can I find out where the threads are stuck?"  I'm not saying
there -is- a solution: quite to the contrary.

Multi-threaded programming (yes, even with a GIL) is here to say in
Ocaml, and I think that the ability to get even a -rudimentary-
"javacore"-like dump, would be useful.  Even in just bytecode mode.

It's been -forever- since I walked around in the ZAM, but Iguess
sometime I'll have to take a look.  In the meantime, does anybody out
there have a -guess- as to the difficulty of getting such a dump out
of the ZAM?

--chet--

On Thursday, April 11, 2013 02:36:06 AM Malcolm Matalka wrote:
> On top of this, I have also had a lot of success using the Result type
> (and associated Monad) instead of Exceptions in Ocaml.  You have to have
> a certain level of discipline to enjoy doing it completely but I have
> never had a stack-trace issue doing it because you already know where
> you have to handle every failure case.
> 
> /M
> 
> Yaron Minsky <yminsky@janestreet.com> writes:
> > 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 <yminsky@janestreet.com> 
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 <murthy.chet@gmail.com> 
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