close_in or close_process_in ?!

close_in or close_process_in ?!

[Oliver Bandel]

Hello,


I stumbled over a problem that I until now have not seen as a problem...


When I use Unix.open_process_in I get as a result the
channel of type in_channel, which means Pervasives.in_channel.

When I open a file with open_in, I get the same type.

Normally a channel of type in_channel, opened with
open_in will be closed with close_in.

An in-channel which was opened with Unix.open_process_in
can (must?) be closed with Unix.close_process_in.


In some code I have used it as described above but always got
a WSIGNALED (-8), when closing a channel that was opened with
Unix.open_process_in. This seems strange to me.


Here is the code, added with some Printf-statements and
exit-statements, which I added to have some output here.

=======================================================================0
module Compressed =
 struct

    let open_gzip_read file     = Unix.open_process_in ("zcat " ^ file)
    let close_gzip_read channel =
           match (Unix.close_process_in channel)
           with   Unix.WEXITED ret -> (* Printf.printf "Status: %d\n"
ret; *)
                     if ret != 0 then Printf.fprintf Pervasives.stderr
"errcode: %d\n" ret
                                 else Printf.fprintf Pervasives.stderr
"OK!"
                | Unix.WSIGNALED sign -> Printf.fprintf
Pervasives.stderr "Signalled.signalled: %d\n" sign ; exit 999
                | Unix.WSTOPPED sign  -> Printf.fprintf
Pervasives.stderr "STOPPED-signalled: %d\n" sign ; exit 111

  end
=======================================================================0
    let id_of_file fname =
      let (opener, closer) =
        if Filename.check_suffix fname ".gz"
        then (Compressed.open_gzip_read, Compressed.close_gzip_read)
        else (open_in, close_in)
      in

      let chan = opener fname in
        let id = try Digest.to_hex( Digest.channel chan 1024 ) with _ ->
"Bad!"
        in
        Printf.printf "RESULT: (%s) => %s\n" fname id;
          closer chan; id
=======================================================================0
Used on a file that can be displayed with zcat by hand:
----------------------------------------------------------
RESULT: (access.log.gz) => 4cf1f6420407714dea9f9d26edee428a
Signalled.signalled: -8

So, zcat can display it, this code fails when closing the file...


When I then change

 "closer chan; id" to
 "close_in chan; id"

I will get:
----------------------------------------------------------

RESULT: (access.log.gz) => 4cf1f6420407714dea9f9d26edee428a
4cf1f6420407714dea9f9d26edee428a


So, this means I get the error message with Signalled -8
when I close with the function that normally should be used.
But the resulting string shows, that the code has worked so far...
...but fails at "closer chan".



So some questions arise:
    *  negative signal-numbers - how can that be?

    * why does that code not work?
      In a different tool I have included that compressed module
      and it works well, tested even with the same gz-file.
      Is there a bug in "id_of_file"?

    * How can it be, that close_process_in as well as close_in
      are working on variables of the same type?
      Isn't this a hole in the typesystem?
      Or can normally both functions, Unix.close_process_in as well
      as Pervasives.close_in be used on that channels?
      And: why is it not working here?


Any ideas here? Do I have a hidden (hidden for my eyes)
bug in my some lines of code, or where is the problem located?!


Ciao,
   Oliver

Re: [Caml-list] close_in or close_process_in ?!

[Olivier Andrieu]

On Jan 21, 2008 1:27 AM, Oliver Bandel <oliver@first.in-berlin.de> wrote:
> Hello,
>
>
> I stumbled over a problem that I until now have not seen as a problem...

> So some questions arise:
>     *  negative signal-numbers - how can that be?

$ ocaml
        Objective Caml version 3.10.0

# Sys.sigpipe ;;
- : int = -8

The caml runtime library just uses negative signal numbers.

>     * why does that code not work?

It does work. It's just that since you close the channel before the
zcat process has finished writing all of the decompressed data, it
dies because it gets a SIGPIPE signal.

>       In a different tool I have included that compressed module
>       and it works well, tested even with the same gz-file.
>       Is there a bug in "id_of_file"?
>
>     * How can it be, that close_process_in as well as close_in
>       are working on variables of the same type?
>       Isn't this a hole in the typesystem?
>       Or can normally both functions, Unix.close_process_in as well
>       as Pervasives.close_in be used on that channels?
>       And: why is it not working here?

Unix.close_process_in calls Pervasives.close_in, ultimately. Before
that, it uses the channel to lookup in a hashtable the pid of the
child process, so as to wait() and report the status of the child
process.

-- 
  Olivier

Re: [Caml-list] close_in or close_process_in ?!

[Oliver Bandel]

Zitat von Olivier Andrieu <oandrieu@nerim.net>:

> On Jan 21, 2008 1:27 AM, Oliver Bandel <oliver@first.in-berlin.de>
> wrote:
> > Hello,
> >
> >
> > I stumbled over a problem that I until now have not seen as a
> problem...
>
> > So some questions arise:
> >     *  negative signal-numbers - how can that be?
>
> $ ocaml
>         Objective Caml version 3.10.0
>
> # Sys.sigpipe ;;
> - : int = -8
[...]

Oh, an unusual way ;-)



>
> The caml runtime library just uses negative signal numbers.
>
> >     * why does that code not work?
>
> It does work. It's just that since you close the channel before the
> zcat process has finished writing all of the decompressed data, it
> dies because it gets a SIGPIPE signal.
[...]


Oaaaaahhhr, yes.
Thanks for the hint.

Normally I read the data complete.
This time I did not (because I only want 1KB
for my Digest). That was, what I have overseen.


>
> >       In a different tool I have included that compressed module
> >       and it works well, tested even with the same gz-file.
> >       Is there a bug in "id_of_file"?
> >
> >     * How can it be, that close_process_in as well as close_in
> >       are working on variables of the same type?
> >       Isn't this a hole in the typesystem?
> >       Or can normally both functions, Unix.close_process_in as well
> >       as Pervasives.close_in be used on that channels?
> >       And: why is it not working here?
>
> Unix.close_process_in calls Pervasives.close_in, ultimately. Before
> that, it uses the channel to lookup in a hashtable the pid of the
> child process, so as to wait() and report the status of the child
> process.
[...]

Because the type that both functions accept are the same,
there should be no problem to use one for the other...
... what's the exit value of a process, that is no process? ;-)
So, channels have some hidden values that take care of
process issues...?!

Ciao,
   Oliver