I am having a problem, where the Ctrl-C stops working as soon as I start 
using the Thread module.

To demonstrate, suppose I have the following code:

------- C --------
#include <caml/mlvalues.h>
#include <caml/signals.h>

value sleep_forever(value foo) {
         caml_enter_blocking_section();
         while(1) {
                 sleep(1);
         }
         caml_leave_blocking_section();
}
------- OCaml -------
external sleep_forever : unit -> unit = "sleep_forever"

let () =
    Sys.catch_break true;
    try
       sleep_forever ()
    with exn ->
       Format.printf "Signal received: %s@." (Printexc.to_string exn)
---------------------

If I compile it normally, run it, and press Ctrl-C, it prints "Signal 
received: Sys.Break" and exits. If I compile it with native threads (and 
  use -linkall to make sure the Thread module is linked in), the exact 
same code fails to react to Ctrl-C!

As far as I can tell, without threads OCaml interrupt handler raises the 
exception right away. With threads, however it simply records the fact 
that Ctrl-C was invoked, and returns back to the C code. When the 
leave_blocking_section is called, the Sys.Break would finally be raised, 
but in my example this never happens :-(.

I understand that in multi-threaded programs the leave_blocking_section 
is needed before returning to OCaml world (as it would acquire the "big 
OCaml lock"), but why can't the interrupt handler simply force that to 
happen? Is there any easy way to have Ctrl-C automatically force 
leave_blocking_section, even in multi-threaded programs?

P.S. The above example is obviously very contrived, but it came from a 
real-world program (OMake) that may have a single thread waiting 
"forever" for an external event (filesystem change notification) inside 
C code...

TIA!

Aleksey

-- 
Aleksey Nogin, Research Scientist
Advanced Technologies Department, Information & System Sciences Lab
HRL Laboratories, LLC, Malibu, CA