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

[Malcolm Matalka <mmatalka@gmail.com>]

Out of curiosity, in what way does Thrift impose threads?  Is it
actually handling socket-layer stuff?

Sorry I can't be of more help, I've successfully managed to avoid using
threads in ocaml except for syscalls.

Chet Murthy <murthy.chet@gmail.com> writes:

> 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