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
Has the thread cancellation problem evolved ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Till Varoquaux <till.varoquaux@g...>
Subject: Re: [Caml-list] Has the thread cancellation problem evolved ?

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 ()
   let computation=Event.send resChan (Some (f arg)) in
 end ()
 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...

On 8/27/07, Daniel Bünzli <> 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:
> Archives:
> Beginner's list:
> Bug reports: