caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Aleksey Nogin <nogin@metaprl.org>
To: Caml List <caml-list@inria.fr>
Subject: In native thread programs, Sys.Break does not get raised inside C blocking sections?
Date: Fri, 27 Jul 2007 13:21:32 -0700	[thread overview]
Message-ID: <46AA53CC.2040003@metaprl.org> (raw)

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


                 reply	other threads:[~2007-07-27 20:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46AA53CC.2040003@metaprl.org \
    --to=nogin@metaprl.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).