Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003747OCamlOCaml generalpublic2005-08-05 20:562005-09-24 10:47
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003747: catch_break does not always catch break
DescriptionFull_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 *)

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000267)
administrator (administrator)
2005-08-10 17:37

> 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
(0000268)
administrator (administrator)
2005-08-10 19:47

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
>
>

(0000269)
administrator (administrator)
2005-09-24 10:47

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

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker