From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6B876431FD0 for ; Sat, 24 Dec 2011 16:37:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnyl769rCpqY for ; Sat, 24 Dec 2011 16:37:47 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by olra.theworths.org (Postfix) with ESMTP id EFB9B431FB6 for ; Sat, 24 Dec 2011 16:37:46 -0800 (PST) X-AuditID: 12074424-b7fae6d000000906-ac-4ef6705ad774 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.6E.02310.A5076FE4; Sat, 24 Dec 2011 19:37:46 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pBP0bkPM002719; Sat, 24 Dec 2011 19:37:46 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBP0biaB027329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 24 Dec 2011 19:37:45 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1Rec6s-00049M-OY; Sat, 24 Dec 2011 19:38:42 -0500 Date: Sat, 24 Dec 2011 19:38:42 -0500 From: Austin Clements To: David Edmondson Subject: Re: [PATCH] Properly handle short writes in sigint handlers Message-ID: <20111225003842.GA15906@mit.edu> References: <20111222201553.GK10376@mit.edu> <1324584948-8009-1-git-send-email-amdragon@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1o0q+OZn8H6TlMW+O1uYLK7fnMns wOSx6/lfJo9nq24xBzBFcdmkpOZklqUW6dslcGV8XMJR8IujYsqlhUwNjD3sXYycHBICJhJf dx1mgrDFJC7cW8/WxcjFISSwj1Hi1+QvUM4GRol1D9YyQzgnmSRmXb/LDuEsYZS4fH4GM0g/ i4CqxMXlrYwgNpuAhsS2/cvBbBEBRYn/31aA7WMWkJb49rsZaB8Hh7CAi8TBE1EgYV4BHYmj 254yQcycwiixcPFyNoiEoMTJmU9YIHq1JG78ewnWCzJn+T8OkDCngI1E15s1YCWiAioSU05u Y5vAKDQLSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECApr dheVHYzNh5QOMQpwMCrx8DYu/eInxJpYVlyZe4hRkoNJSZQ3P/+bnxBfUn5KZUZicUZ8UWlO avEhRgkOZiURXs0koHLelMTKqtSifJiUNAeLkjivhtY7PyGB9MSS1OzU1ILUIpisDAeHkgTv c5ChgkWp6akVaZk5JQhpJg5OkOE8QMMPgNTwFhck5hZnpkPkTzHqcixeteEsoxBLXn5eqpQ4 716QIgGQoozSPLg5sHT0ilEc6C1h3uUgVTzAVAY36RXQEiagJTFGIB8UlyQipKQaGD26LJw1 PQw1jWR49yV2yE1hvr84dWJ08tT4us9/c/NSmLvWtN089v1CTZX0eXWZxPQ0MUWDGcuzP+5f 9D5A/Lpm/IavzzyjfYN+bD5a9yr05bHUf9eu9a5Wqm3f+byjxVk+QffTl4RszsV1R2qXir0o Pah4sXt2TPH78+U31D1fMrO6WH1pUWIpzkg01GIuKk4EADjf7HwiAwAA Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 00:37:47 -0000 Quoth David Edmondson on Dec 23 at 8:10 am: > Sorry for being slow. > > Can you describe the situation in which you expect a write to stderr to > be a short write? (Without error.) If the PTY buffer is nearly full because, say, my terminal emulator is a little behind or my SSH session is slow, I believe POSIX allows this to be a short write (though Linux appears to treat PTYs like pipes and will block rather than doing a short write, so it's completely possible I'm misinterpreting POSIX). > In that situation, what guarantee is there that the loop you've written > will terminate? There isn't, but for the same reason there's also no guarantee that a single write will terminate. > We're not talking about safeguarding a users' data here - this is a > short message to indicate that a tool is terminating due to a signal. > I'm concerned that the solution is worse than the problem. As a user I'd be confused to see just part of the "Stopping" message jammed in the middle of other output, but you're definitely right that the consequences of this would not extend beyond a little bit of harmless confusion.