Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

catch_break does not always catch break #3747

Closed
vicuna opened this issue Aug 5, 2005 · 9 comments
Closed

catch_break does not always catch break #3747

vicuna opened this issue Aug 5, 2005 · 9 comments
Labels
feature-wish known-limitation Acknowledge the problem, but there is no plan to fix it Stale stdlib

Comments

@vicuna
Copy link

vicuna commented Aug 5, 2005

Original bug ID: 3747
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: runtime system and C interface

Bug description

Full_Name: Henri
Version: 3.08.2
OS: linux
Submission from: aorleans-104-1-15-86.w80-11.abo.wanadoo.fr (80.11.35.86)

The following program never catches Ctrl+C in a terminal and loops forever.

let _ =
  Sys.catch_break true;
  try 
    while true do
      ()
    done
  with 
    Sys.Break -> prerr_endline "QUIT!"

The following program works as expected though!

let _ =
  Sys.catch_break true;
  try 
    while true do
      ignore (input_line stdin)
    done
  with 
    Sys.Break -> prerr_endline "QUIT!"

The following program does not catch break of course, but exits properly when
Ctrl+C is pressed in the same environment.

let _ =
  try 
    while true do
      ()
    done
  with 
    Sys.Break -> prerr_endline "QUIT!" (* useless, kept anyway *)
@vicuna
Copy link
Author

vicuna commented Aug 10, 2005

Comment author: administrator

Full_Name: Henri
Version: 3.08.2
OS: linux

The following program never catches Ctrl+C in a terminal and loops forever.
let _ =
Sys.catch_break true;
try
while true do
()
done
with
Sys.Break -> prerr_endline "QUIT!"

This is because signal handling has to be synchronized by the OCaml runtime:
when a signal is caught, it sets a flag which is checked by the program from
time to time... except in the rare case of a loop that doesn't allocate and
doesn't call any function and is compiled with ocamlopt.

The solution would be for the compiler to insert a test in every loop, but
is it worth the trouble for something that almost never happens in a real
program?

The following program does not catch break of course, but exits properly when
Ctrl+C is pressed in the same environment.
let _ =
try
while true do
()
done
with
Sys.Break -> prerr_endline "QUIT!" (* useless, kept anyway *)

In this case, the signal is not caught, but the OS kills the process directly.

-- Damien

@vicuna
Copy link
Author

vicuna commented Aug 10, 2005

Comment author: administrator

Damien,
Thank you very much for the answer - maybe this should be added to the
catch_break description. Btw, the third example was just meant to show
that my *term works correctly (which should never be taken for granted
nowadays!).
Regards,
Henri

On 8/10/05, Damien Doligez caml-bugs@pauillac.inria.fr wrote:

Full_Name: Henri
Version: 3.08.2
OS: linux

The following program never catches Ctrl+C in a terminal and loops forever.
let _ =
Sys.catch_break true;
try
while true do
()
done
with
Sys.Break -> prerr_endline "QUIT!"

This is because signal handling has to be synchronized by the OCaml runtime:
when a signal is caught, it sets a flag which is checked by the program from
time to time... except in the rare case of a loop that doesn't allocate and
doesn't call any function and is compiled with ocamlopt.

The solution would be for the compiler to insert a test in every loop, but
is it worth the trouble for something that almost never happens in a real
program?

The following program does not catch break of course, but exits properly when
Ctrl+C is pressed in the same environment.
let _ =
try
while true do
()
done
with
Sys.Break -> prerr_endline "QUIT!" (* useless, kept anyway *)

In this case, the signal is not caught, but the OS kills the process directly.

-- Damien

@vicuna
Copy link
Author

vicuna commented Sep 24, 2005

Comment author: administrator

Issue is documented in ocamlopt chapter of ref. man. Feature wish: better
polling for signals in ocamlopt-generated code. Unlikely to change any time
soon. XL, 2005-09-24

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

I think such better polling for signals might arrive with multicore, but I don't remember the details.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 18, 2020
@mshinwell
Copy link
Contributor

This is a known problem with the current implementation of safe points that will be addressed by the multicore work. Given that, I don't think this old issue needs to remain open.

@stedolan
Copy link
Contributor

Reopened because this is still an issue. There's some discussion about a potential fix in the multicore repo at ocaml-multicore/ocaml-multicore#187.

@stedolan stedolan reopened this May 18, 2020
@github-actions github-actions bot removed the Stale label Jun 29, 2020
@damiendoligez damiendoligez added the known-limitation Acknowledge the problem, but there is no plan to fix it label Oct 16, 2020
@sadiqj sadiqj mentioned this issue Nov 22, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Oct 18, 2021
@xavierleroy
Copy link
Contributor

Fixed by the "safepoints" PR #10039.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-wish known-limitation Acknowledge the problem, but there is no plan to fix it Stale stdlib
Projects
None yet
Development

No branches or pull requests

5 participants