Hmm,

I have a very partial answer. I had to implement timeouts on blocking
calls recently I had to resort to alarms. You seem to be well
documented so I don't think this will be new to you. It might however
be useful to less seasoned hackers.

Here is the sample code:

exception Timeout
let timeout timeout f arg=
 let resChan=Event.new_channel () in
 let res=Event.receive resChan in
 let _= Thread.create begin
  fun () ->
   Unix.alarm timeout;
   Sys.signal Sys.sigalrm (Sys.Signal_handle begin
                            fun _ ->
                             Event.sync(Event.send resChan None);
                             Thread.exit ()
                           end);
   let computation=Event.send resChan (Some (f arg)) in
   Event.sync(computation)
 end ()
 in
 match Event.sync(res) with
  | Some e -> e
  | None -> raise Timeout

let _ =
 let r=timeout 1 (fun a -> Thread.delay 1.5; a) "arg" in
 print_string r


As a side note I thinks Threads.raise_in would be awesome, it might be
hard to add in the language though...

Till
On 8/27/07, Daniel Bünzli <daniel.buenzli@epfl.ch> wrote:
>
> Le 25 août 07 à 17:29, skaller a écrit :
>
> > There is something I don't understand here.
>
> What you don't understand is that ocaml has a runtime system which
> leaves some room for designing around what exists at the os level.
>
> > If the source of the problem is a blocking operation, the solution
> > is simple: don't use blocking operations!
>
> This is not the source of the problem. What I want is to allow users
> to initiate and cancel computations whenever they want. Computations
> can be lengthy even tough they do not invoke a blocking operation.
>
> The problem is that libraries are not -- and should not -- be
> designed with cancellation in mind, say every function has an
> optional parameter that allows to stop the computation. Cancellation
> should be a service of the runtime system, and denying its usefulness
> because it could be misused makes no sense, I can also open a file
> and never close it, it is a matter of programming discipline.
>
> Daniel
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>