From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,PLING_QUERY autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 07E11BC6B for ; Mon, 21 Jan 2008 03:12:26 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALaOk0fAXQInh2dsb2JhbACQGgEBAQgKKZl/ X-IronPort-AV: E=Sophos;i="4.25,224,1199660400"; d="scan'208";a="8094761" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Jan 2008 03:12:25 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0L2CP6h002640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 21 Jan 2008 03:12:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB6Nk0fAbSoIh2dsb2JhbACQGgEBAQgKKZoD X-IronPort-AV: E=Sophos;i="4.25,224,1199660400"; d="scan'208";a="6333737" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Jan 2008 03:12:25 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m0L2COWW011418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Jan 2008 03:12:24 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m0L2COJM011416 for caml-list@inria.fr; Mon, 21 Jan 2008 03:12:24 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-101-229.pools.arcor-ip.net (dslb-088-073-101-229.pools.arcor-ip.net [88.73.101.229]) by webmail.in-berlin.de (IMP) with HTTP for ; Mon, 21 Jan 2008 03:12:24 +0100 Message-ID: <1200881544.4793ff88073ca@webmail.in-berlin.de> Date: Mon, 21 Jan 2008 03:12:24 +0100 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] close_in or close_process_in ?! References: <1200875269.4793e705712e3@webmail.in-berlin.de> <95513600801201658i3b641976i2aea380ef7f4e302@mail.gmail.com> In-Reply-To: <95513600801201658i3b641976i2aea380ef7f4e302@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at concorde with ID 4793FF89.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 andrieu:01 oandrieu:01 bandel:01 in-berlin:01 ocaml:01 runtime:01 bug:01 pervasives:01 pervasives:01 hashtable:01 wrote:01 unix:01 unix:01 Zitat von Olivier Andrieu : > On Jan 21, 2008 1:27 AM, Oliver Bandel > 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