caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Christian Schaller <Christian.Schaller@siemens.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] closing file descriptors and channels
Date: Thu, 20 Nov 2003 17:35:38 +0100	[thread overview]
Message-ID: <20031120173538.B14255@pauillac.inria.fr> (raw)
In-Reply-To: <A1364BC6814D92479D4EED572D6F6FD806953B@uranus.certw2k.net>; from Christian.Schaller@siemens.com on Thu, Nov 20, 2003 at 05:14:11PM +0100

> Can anyone tell me how to close a file descriptor successfully?  In the
> code below
> 
> (* Append new line if condition cond is not satisfied on any line.
>    Otherwise, raise exception and return the line that fulfills the
> condition. *)
> let append_line_cond file_name line cond = 
>   let file_descr = Unix.openfile file_name [Unix.O_RDWR; Unix.O_APPEND]
> 0o644 in
>   let ic = Unix.in_channel_of_descr file_descr in
>   let oc = Unix.out_channel_of_descr file_descr in
>   try
>   (* Read line by line and check if condition is true.  If so, leave the
>      function and return the line that satisfied the condition *)
>   while true do 
>     let line = input_line ic in
>     if cond line
>     then raise (Found line)
>   done          
>   with          
>   End_of_file -> output_string oc (line ^ "\n");
>   (* close all channels *)
>   Unix.close file_descr;
>   close_out oc;
>   close_in ic
> 
> I get a Sys_error "Bad file descriptor".  As far as I figured out, the
> problem is related with the creation of the two channels for input and
> output.  If I comment out the Unix.close, everything works fine, but I
> don't know if the file_descr will be automatically closed.  Hm...

close_out and close_in both perform the equivalent of a Unix.close on
the underlying Unix file descriptor, and, yes, closing something that
is already closed is an I/O exception.  So, one possibility is to
close only one of the three entities file_descr, oc and ic.  It's best
to close the output channel oc, since this will flush its buffer.

The other possibility is to use close_out_noerr and close_in_noerr
that will just ignore the errors arising from the closing of the
underlying file descriptor.  But this can be dangerous: certain
implementations of NFS can report write errors not at the time of the
writing, but at the time of the closing, and presumably you're
interested in getting these errors reported.

Side remark: you'd need to close the file descriptor also in the case
where the line is found and the exception Found is raised.

> Yet another closing-channels-question.  If I use streams instead of
> reading a file line by line, where exactly do I have to close the
> channel?  Is close_in on the right position below?
> 
> let read_lines ch =
>   let read_new_line n =
>     try Some (input_line ch)
>     with End_of_file -> close_in ch in
>   Stream.from read_new_line

This looks fine, except that you need to return None in the
End_of_file case.  (The typechecker will remind you about this :-)

Hope this helps,

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2003-11-20 16:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-20 16:14 Christian Schaller
2003-11-20 16:35 ` Xavier Leroy [this message]
2003-11-20 17:01   ` Tim Freeman
2003-11-20 17:14   ` Nicolas George
2003-11-20 16:55 Christian Schaller
2003-11-20 16:54 ` Tim Freeman
2003-11-21 16:28   ` skaller

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=20031120173538.B14255@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=Christian.Schaller@siemens.com \
    --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).