From owner-freebsd-stable@FreeBSD.ORG Mon Sep 19 06:18:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41246106564A for ; Mon, 19 Sep 2011 06:18:38 +0000 (UTC) (envelope-from chris.torek@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F05DA8FC0C for ; Mon, 19 Sep 2011 06:18:37 +0000 (UTC) Received: by yxk36 with SMTP id 36so4800203yxk.13 for ; Sun, 18 Sep 2011 23:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aoOkNiaBo2k7tyoek5bXt9ejUnSDYZUI1Td/zNtDfbk=; b=M+K6ZCrQJSMOaG91F0QfKAIn6KbvrQCaILCwAH7zyd3eROvOR0249CzVsF6YGkIlok 5Tjr2bwvk/U7uLz/o5zFR1ghxkoy6QuB2qAJ31HGA5DHa4LvTVOwnymkaKeMHr183mAy eRv2Nlt1G+TE9sv8MDr+Ol1qzsj92RONRcEc4= MIME-Version: 1.0 Received: by 10.150.148.16 with SMTP id v16mr1703069ybd.396.1316411366095; Sun, 18 Sep 2011 22:49:26 -0700 (PDT) Received: by 10.150.138.13 with HTTP; Sun, 18 Sep 2011 22:49:25 -0700 (PDT) In-Reply-To: <20110918172423.GB1511@deviant.kiev.zoral.com.ua> References: <20110918045413.GA63773@DataIX.net> <20110918053901.GA31617@icarus.home.lan> <86d3eydsmf.fsf@kopusha.home.net> <868vpmdq11.fsf@kopusha.home.net> <20110918172423.GB1511@deviant.kiev.zoral.com.ua> Date: Sun, 18 Sep 2011 23:49:25 -0600 Message-ID: From: Chris Torek To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mikolaj Golub , "freebsd-stable@freebsd.org" , Jeremy Chadwick , cperciva@freebsd.org, Ronald Klop Subject: Re: /usr/bin/script eating 100% cpu with portupgrade and xargs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 06:18:38 -0000 On Sep 18, 2011 11:25 AM, "Kostik Belousov" wrote: > Please note that interpreting the receiving of 0 bytes on the terminal > as EOF is only a convention. If done absolutely properly, script shall > not interpret zero-byte read as EOF. Might be, the reasonable thing to > do would be to only look at the stdin once in a second after receiving > zero-bytes, and switching it back to normal mode if something is read. The other obvious alternative is to test for underlying file type, and distinguish between "EOF is forever" (ordinary pipes and sockets, some but not all block devices, etc) and "other".=A0 In fact, the "EOF is only temporary" mode introduced in the original change might reasonably be limited to character devices only, for the purposes to which script is put. The delay method has significant merit in terms of simplicity, of course: it avoids special-casing. To truly fix the problem, though, you would need something different in terms of a kernel interface: a message from the master side of the pty saying "slave side has done a read(n)" (where n is some integer), so that the program running the pty can issue a corresponding read(n) on a buffer, to forward the results back through the pty later. Without this, the "script" program erroneously translates one "EOF as signaled by read returning 0" into multiple "EOF on pty" signals. Adding a delay simply changes this from "as many as script can stuff down the pty at maximum CPU rate" to "one a second". Thus, if I were fixing this, I would lean towards "EOF is just a temporary signal" being applied only to character devices, and/or perhaps having a command-line flag to force one mode or the other (with the default being "EOF is permanent on everything except character devices"). Chris