From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] close_in or close_process_in ?!
Date: Mon, 21 Jan 2008 03:12:24 +0100 [thread overview]
Message-ID: <1200881544.4793ff88073ca@webmail.in-berlin.de> (raw)
In-Reply-To: <95513600801201658i3b641976i2aea380ef7f4e302@mail.gmail.com>
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
prev parent reply other threads:[~2008-01-21 2:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-21 0:27 Oliver Bandel
2008-01-21 0:58 ` [Caml-list] " Olivier Andrieu
2008-01-21 2:12 ` Oliver Bandel [this message]
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=1200881544.4793ff88073ca@webmail.in-berlin.de \
--to=oliver@first.in-berlin.de \
--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