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

[Francois Berenger <berenger@riken.jp>]

On 04/11/2013 07:28 AM, simon cruanes wrote:
> An interesting solution for the safe resource acquisition/release, I
> believe, is the Go statement "defer" [1]. In OCaml, you would write
> something like:
>
> let my_fun () =
>    Mutex.lock some_lock;
>    defer (fun () -> Mutex.unlock some_lock);
>    (* critical section to the end of the block *)
>    ....
>    let final_result = 42 in
>    final_result   (* returns, but runs defer-ed statements first *)
>
> In case an exception is thrown before the function returns, defer-ed
> statements would still be executed, before the exception is raised again
> (with the full stacktrace). Defer-ed statements are executed in the
> reverse order of their definitions. It also works for resources like
> files, sockets, etc.

There is at_exit from Pervasives that looks like a defer, but only
at the program level unfortunately.

I think I read that at Citrix thay garbage-collect everything:
open files, acquired locks, etc.
I have no idea of how they manage to do this, however.

Regards,
F.

> Simon
>
> [1] http://blog.golang.org/2010/08/defer-panic-and-recover.html
>
> On 11/04/2013 00:16, 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--
>>
>>
>>
>
>