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_
next prev parent 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