bf/957ccd3438a41f260ecdae4e59abec37a0fbc1

   1 Return-Path: <amdragon@mit.edu>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 36E78429E31\r
   6         for <notmuch@notmuchmail.org>; Sat, 24 Dec 2011 16:37:57 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id mKXeaSn351hH for <notmuch@notmuchmail.org>;\r
  16         Sat, 24 Dec 2011 16:37:55 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU\r
  18         [18.7.68.35])\r
  19         by olra.theworths.org (Postfix) with ESMTP id E9633429E28\r
  20         for <notmuch@notmuchmail.org>; Sat, 24 Dec 2011 16:37:54 -0800 (PST)\r
  21 X-AuditID: 12074423-b7f9c6d0000008c3-be-4ef6706270b8\r
  22 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
  23         by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id CA.6E.02243.26076FE4; Sat, 24 Dec 2011 19:37:54 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id pBP0brOB014459; \r
  27         Sat, 24 Dec 2011 19:37:54 -0500\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBP0bpJn027338\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sat, 24 Dec 2011 19:37:53 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@MIT.EDU>)\r
  36         id 1Rec70-00049Q-18; Sat, 24 Dec 2011 19:38:50 -0500\r
  37 Date: Sat, 24 Dec 2011 19:38:50 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Tomi Ollila <tomi.ollila@iki.fi>\r
  40 Subject: Re: [PATCH] Properly handle short writes in sigint handlers\r
  41 Message-ID: <20111225003850.GF1927@mit.edu>\r
  42 References: <20111222201553.GK10376@mit.edu>\r
  43         <1324584948-8009-1-git-send-email-amdragon@mit.edu>\r
  44         <cunhb0rvhc6.fsf@hotblack-desiato.hh.sledj.net>\r
  45         <yf6fwgba2rp.fsf@taco2.nixu.fi>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=us-ascii\r
  48 Content-Disposition: inline\r
  49 In-Reply-To: <yf6fwgba2rp.fsf@taco2.nixu.fi>\r
  50 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  51 X-Brightmail-Tracker:\r
  52  H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1k0q+OZnsK1R1WLfnS1MFtdvzmS2\r
  53         eLNyHqsDs8eu53+ZPA5/Xcji8WzVLeYA5igum5TUnMyy1CJ9uwSujJ9ntrMVNIpW9Fx/ztTA\r
  54         eEagi5GDQ0LAROL9FZEuRk4gU0ziwr31bF2MXBxCAvsYJQ7sXcMC4WxglNj3roEJwjnJJLH9\r
  55         xVqosiWMEvfa97GC9LMIqEqsmnOXGcRmE9CQ2LZ/OSOILSKgIvGgbT1YDbOAlcTFZ3vYQVYL\r
  56         C7hIHDwRBRLmFdCWONf7nhli5jZGifUdb1ghEoISJ2c+YYHo1ZK48e8lE0gvs4C0xPJ/HCBh\r
  57         TgEdiWlPb4KViAKtmnJyG9sERqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5q\r
  58         ka6ZXm5miV5qSukmRlCos7so72D8c1DpEKMAB6MSD2/z0i9+QqyJZcWVuYcYJTmYlER58/O/\r
  59         +QnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4dVMAirnTUmsrEotyodJSXOwKInzami98xMSSE8s\r
  60         Sc1OTS1ILYLJynBwKEnwrgYZKliUmp5akZaZU4KQZuLgBBnOAzT8AEgNb3FBYm5xZjpE/hSj\r
  61         opQ4716QhABIIqM0D64XlopeMYoDvSLMuxykigeYxuC6XwENZgIaHGMEcnVxSSJCSqqB8e6C\r
  62         9A5V+wVBc/OOmim4P85fVxz7QCTh9lq3B0yTy/MvcClNXH1AKklLYSLzooAdZw6GhKy/MNdi\r
  63         273lVUHr6h6f1pF5US+2+PP2A8y1uc9cLpdntBgumxM3hVuY0ftNop/JbsYl//a+CNfQLHzH\r
  64         yOaQyBlUY3xd4Al3fF6gGIvkP7bvezI2KLEUZyQaajEXFScCAPlkKlYgAwAA\r
  65 Cc: notmuch@notmuchmail.org\r
  66 X-BeenThere: notmuch@notmuchmail.org\r
  67 X-Mailman-Version: 2.1.13\r
  68 Precedence: list\r
  69 List-Id: "Use and development of the notmuch mail system."\r
  70         <notmuch.notmuchmail.org>\r
  71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  74 List-Post: <mailto:notmuch@notmuchmail.org>\r
  75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  78 X-List-Received-Date: Sun, 25 Dec 2011 00:37:57 -0000\r
  79 \r
  80 Quoth Tomi Ollila on Dec 23 at  2:30 pm:\r
  81 > On Fri, 23 Dec 2011 08:10:33 +0000, David Edmondson <dme@dme.org> wrote:\r
  82 > > Sorry for being slow.\r
  83 > > \r
  84 > > Can you describe the situation in which you expect a write to stderr to\r
  85 > > be a short write? (Without error.)\r
  86 > \r
  87 > In the following hypothetical case (correct me if I'm wrong :):\r
  88 > \r
  89 > * There is 4096 byte buffer in tty driver.\r
  90 > * Stderr is in blocking-mode (the usual case).\r
  91 > * There is already 4090 bytes in that buffer that has not been read.\r
  92 > * One attemtps to write "Stopping...         \n" there (blocks).\r
  93 > * Somehow the system call is interrupted (and SA_RESTART not set)\r
  94 >   -- write() should return 6 bytes written.\r
  95 \r
  96 This is one possibility.  It's also possible it will write no bytes\r
  97 and fail with EINTR.  Depending on the type of the stderr file\r
  98 descriptor, it's possible for write to return immediately with 6,\r
  99 even without a signal interrupting it.\r
 100 \r
 101 > But, if the buffer is full already, does the write() system call return\r
 102 > with -1 and EINTR set ?\r
 103 \r
 104 write only returns EINTR if it was interrupted by a signal before\r
 105 anything was written.  If the buffer is full already, write will block\r
 106 (unless it's in non-blocking mode, in which case it will write nothing\r
 107 and fail with EAGAIN or EWOULDBLOCK).\r
 108 \r
 109 > If there is enough space for all data in that buffer to begin with, \r
 110 > write() should be atomic.\r
 111 > \r
 112 > > In that situation, what guarantee is there that the loop you've written\r
 113 > > will terminate?\r
 114 > \r
 115 > If write() keeps returning 0 then it will not terminate (I guess this never\r
 116 > happens). Also, it never terminates if write blocks indefinitely \r
 117 > (with or without that loop).\r
 118 \r
 119 I believe the only way write can return 0 is if you pass it a zero\r
 120 length.\r
 121 \r
 122 > > We're not talking about safeguarding a users' data here - this is a\r
 123 > > short message to indicate that a tool is terminating due to a signal.\r
 124 > > I'm concerned that the solution is worse than the problem.\r
 125 > \r
 126 > I'm also in favor of "opportunistic" write *in this particular case*\r
 127 > \r
 128 > In case that write fails there is most probably more serious things going\r
 129 > on (all resources eaten, hardware problem, etc) and trying to push these\r
 130 > writes forward doesn't help.\r
 131 \r
 132 This I find more persuasive.  I've been concerned about notmuch doing\r
 133 strange things (with admittedly minor consequences) under common\r
 134 circumstances (like transient buffer overflows), but you're right that\r
 135 more severe circumstances could warrant an opportunistic approach.  Of\r
 136 course, we're also not depending on the sigint handler for\r
 137 correctness; if notmuch somehow wedges in it then you're notmuch worse\r
 138 off than you would be otherwise.\r