caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ian T Zimmerman <itz@transbay.net>
To: caml-list@inria.fr
Subject: Re: Catching Break?
Date: 08 Feb 1999 23:02:52 -0800	[thread overview]
Message-ID: <m2socg2h5v.fsf@kronstadt.transbay.net> (raw)
In-Reply-To: Ian T Zimmerman's message of 06 Feb 1999 00:24:18 -0800

Ian T Zimmerman <itz@transbay.net> writes:

> 
> Ian T Zimmerman <itz@transbay.net> writes:
> 
> >  Ok, I see that I'll have to start posting my real code, because I
> > still can't make it work despite (imperfect) analogy with the
> > example.
> >  let remove_pair prefix pid =
> >   let spid = string_of_int pid in let iname = prefix ^ spid ^ ".i"
> >   and oname = prefix ^ spid ^ ".o" in Sys.remove iname; Sys.remove
> >   oname
> >  let open_pair prefix pid respond =
> >   let spid = string_of_int pid in let iname = prefix ^ spid ^ ".i"
> >   and oname = prefix ^ spid ^ ".o" and iflags = [Unix.O_RDONLY ;
> >   Unix.O_NONBLOCK] and oflags = [Unix.O_WRONLY] in let id x = x in
> >   Sys.catch_break true; let (ind, outd) = try if respond then
> >     let outd = Unix.openfile iname oflags 0 in let ind =
> >     Unix.openfile oname iflags 0 in id (ind, outd)
> >   else
> >     let ind = Unix.openfile iname iflags 0 in let outd =
> >     Unix.openfile oname oflags 0 in (* HERE! *) id (ind, outd)
> >   with Sys.Break ->
> >     if not respond then remove_pair prefix pid; Sys.catch_break
> >     false; exit 0; assert false in
> >   Sys.catch_break false; (ind, outd)
> >
> >  The files referred to by [io]name are named pipes; the write open
> > hangs until the other side is opened, which may never happen.  So as
> > to have a chance to clean up (namely remove the pipes), I must allow
> > _and_ catch Control-C as I'm trying to.  But it doesn't work; if I
> > hit Control-C while blocked in the open marked, I never get into the
> > with handler.
> >
> 
> I tried this:
> 
> let remove_pair prefix pid = 
>   let spid = string_of_int pid in
>   let iname = prefix ^ spid ^ ".i"
>   and oname = prefix ^ spid ^ ".o" in
>   Sys.remove iname; Sys.remove oname
> 
> let open_pair prefix pid respond =
>   let spid = string_of_int pid in
>   let iname = prefix ^ spid ^ ".i"
>   and oname = prefix ^ spid ^ ".o" 
>   and iflags = [Unix.O_RDONLY ; Unix.O_NONBLOCK]
>   and oflags = [Unix.O_WRONLY] in
>   Sys.catch_break true;
>   let (ind, outd) = try if respond then
>     let outd = Unix.openfile iname oflags 0 in
>     let ind = Unix.openfile oname iflags 0 in
>     for i = 0 to 1 do () done; (ind, outd)
>   else
>     let ind = Unix.openfile iname iflags 0 in
>     let outd = Unix.openfile oname oflags 0 in
>     for i = 0 to 1 do () done; (ind, outd)
>   with Sys.Break ->
>     if not respond then remove_pair prefix pid;
>     Sys.catch_break false; exit 0;
>     assert false in
>   Sys.catch_break false; (ind, outd)
> 
> 
> ... and it doesn't work, either :-(
> I am really stumped, please help.
> 

I think I have figured this out, at last.  I _have_ overlooked
something quite simple, so I'm a bit ashamed, but maybe it also
qualifies as a minor bug in Ocaml and that's why I'm getting over my
shame and posting this.

The trouble is that there are _two_ exceptions involved here: one
(Sys.Break) set up by the signal handler, and _another_
(Unix.Unix_error) raised by the openfile primitive when the true
open() fails with errno == EINTR.  There was no handler for Unix_error
in my code and that's the reason for the "Uncaught exception"
behaviour; OTOH, the runtime system doesn't seem to be prepared for
this situation and raises Break regardless, at the next "safe point"
which happens to be in the catch_all exception handler.

The only solution I have found is to set up my own sigint handler:

let remove_pair prefix pid = 
  let spid = string_of_int pid in
  let iname = prefix ^ spid ^ ".i"
  and oname = prefix ^ spid ^ ".o" in
  Sys.remove iname; Sys.remove oname

let safe_open name flags mode =
  let break_handler _ = () in
  let old_handler = Sys.signal Sys.sigint (Sys.Signal_handle break_handler) in
  let d = Unix.openfile name flags mode in
  Sys.set_signal Sys.sigint old_handler; d

let open_pair prefix pid respond =
  let spid = string_of_int pid in
  let iname = prefix ^ spid ^ ".i"
  and oname = prefix ^ spid ^ ".o" 
  and iflags = [Unix.O_RDONLY ; Unix.O_NONBLOCK]
  and oflags = [Unix.O_WRONLY] in
  let (ind, outd) = try if respond then
    let outd = safe_open iname oflags 0 in
    let ind = safe_open oname iflags 0 in
    (ind, outd)
  else
    let ind = safe_open iname iflags 0 in
    let outd = safe_open oname oflags 0 in
    (ind, outd) 
  with any ->
    if not respond then remove_pair prefix pid;
    raise any in (ind, outd)


Now I receive _only_ the Unix_error exception, and I clean up as
intended.


IMO there are two possible changes to Ocaml that can fix this
confusing situation:

o	Do not run the delayed ML signal handlers while in a 
        "with .." block.  This is like considering ML synchronous
        exceptions as "highest priority" signals. I can see how this
        could be difficult, though, with a global state flag needed,
        interaction with threads etc.

o       Within unix_error (in otherlibs/unix/unixsupport.c) check if
        Sys.sigint is pending and Sys.catch_break has been set, and if
        so, do nothing (rather than raise Unix_error).  I can see how
        this could be difficult as well - is there any way for C
        primitive code to access the runtime internals like this?

Best,

-- 
Ian T Zimmerman                        <itz@transbay.net>
I came to the conclusion that what was wrong about the guillotine
was that the condemned man had no chance at all, absolutely none.
Albert Camus, _The Outsider_




  reply	other threads:[~1999-02-09  8:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-25 18:43 Ian T Zimmerman
1999-01-26  0:24 ` Xavier Leroy
1999-01-26  6:46   ` Ian T Zimmerman
1999-01-28 11:14     ` Xavier Leroy
1999-01-28 17:33       ` Ian T Zimmerman
1999-02-06  8:24         ` Ian T Zimmerman
1999-02-09  7:02           ` Ian T Zimmerman [this message]
1999-02-10 15:48             ` Xavier Leroy
1999-02-05 18:00   ` Ian T Zimmerman
1999-02-08 17:16     ` Xavier Leroy
1999-01-26  5:17 Frank A. Christoph
1999-01-26 11:23 Toby Moth

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=m2socg2h5v.fsf@kronstadt.transbay.net \
    --to=itz@transbay.net \
    --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).