From unknown Fri Jun 20 07:16:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#66020 <66020@debbugs.gnu.org> To: bug#66020 <66020@debbugs.gnu.org> Subject: Status: [PATCH] Reduce GC churn in read_process_output Reply-To: bug#66020 <66020@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:16:07 +0000 retitle 66020 [PATCH] Reduce GC churn in read_process_output reassign 66020 emacs submitter 66020 Dmitry Gutov severity 66020 wishlist tag 66020 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 15 21:26:35 2023 Received: (at submit) by debbugs.gnu.org; 16 Sep 2023 01:26:35 +0000 Received: from localhost ([127.0.0.1]:45112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhK4w-0000a1-UD for submit@debbugs.gnu.org; Fri, 15 Sep 2023 21:26:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:56812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhK4u-0000Zi-N9 for submit@debbugs.gnu.org; Fri, 15 Sep 2023 21:26:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhK4i-00021c-GV for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 21:26:20 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhK4f-0003bU-VL for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 21:26:20 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8492D320091A for ; Fri, 15 Sep 2023 21:26:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 15 Sep 2023 21:26:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1694827573; x=1694913973; bh=SdGI/sXivr/Bm6TEtmwbQHn/9 D9AGPCQdOVUfR48L78=; b=bJhrmA6/9vzWz0up4od2li6f1mpcaj8V0IKIl5t89 oDXcG06Su9fW7E5B8aF8b1dYzYfxQb68/KHlzTyr6VkDvVBjsnSvA0rlIYjf1WoQ 1F7wGrM5XrSu0M+Qg07iwoLop0EZk5tF/pzjvyvOmOYtLxEVExa0VIiPva/5VOEO QGBTISbAxyFTCKAAY+9k8j2cSyYHdu19ssS2uoOrjhMvhI0IZ/qQrbJjXj2Ms8b/ iWTx6bsJO3X+qk/quZmHGBRDX0qaUttFBUIhreovWacvQlOy1b4n8kvYHboHgww+ 0JZD53je2Si4gf4Bttj+qlHOXL+RWtkXqLRKmFgqI/ZwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1694827573; x=1694913973; bh=SdGI/sXivr/Bm6TEtmwbQHn/9D9AGPCQdOV UfR48L78=; b=GgZaUFFbGkGiH4pVQnQCkhwr7PgUCyxTV4cB9mN9baFxB8lPPfH MSqBBgvkpRKPc/9KVfLTrt9y5jBHcO13+ZoCxkqHLg8Um+7rawJELtkZVKy2F7IJ ilJMFWcqNhibiDoYfdLRZA0hJdTDZp4qxZfDJqoTiMCRn+g9YxdSZsieQ+o+D8nq sEzfppXXtkT6DSph2u0s2b/7wog3oPBPbd28LR+7j5rvF9ErmkqtI8nA/xk8rz8m GStzbX9WEQwW4JNIlzinjddpDwiKe8OOpMFAKxNm8Q7zFsiu0YwiN3dI2XTCeKM+ DHKjyxsQkdFCgFpDMdrMFiRb2k/Xpghobcg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejfedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtkfffgggfvffhufesmhdtreertd efjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhv rdguvghvqeenucggtffrrghtthgvrhhnpeduteeijeeiveehveehtdehjefhtdevuedtie efffeivdeijeejvdevveegvdevvdenucffohhmrghinhepghhnuhdrohhrghenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesgh huthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 15 Sep 2023 21:26:13 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------ujujwY71SxzZu4tHORIFXUna" Message-ID: <3a6287c3-8458-663e-ffce-8f48b30bf73d@gutov.dev> Date: Sat, 16 Sep 2023 04:26:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: bug-gnu-emacs@gnu.org From: Dmitry Gutov Subject: [PATCH] Reduce GC churn in read_process_output Received-SPF: pass client-ip=64.147.123.21; envelope-from=dmitry@gutov.dev; helo=wout5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) This is a multi-part message in MIME format. --------------ujujwY71SxzZu4tHORIFXUna Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As suggested, I'm filing this in a new bug report for wider review. The updated patch attached. The previous discussion was in bug#64735, and the benchmarks (which more or less hold for the new patch as well) can be viewed here (last table): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64735#506. Except the new version somehow performs a little better at read-process-output-max=4096 as well, despite seemingly doing more. Let me know if I DRYed this too much, or if there are better names for the extracted common routines, or etc. Or for the new variable (read-process-output-fast). --------------ujujwY71SxzZu4tHORIFXUna Content-Type: text/x-patch; charset=UTF-8; name="read_and_insert_process_output_v2.diff" Content-Disposition: attachment; filename="read_and_insert_process_output_v2.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9wcm9jZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IDA4Y2I4 MTBlYzEzLi44ZWFkNTA4YjcyNiAxMDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9z cmMvcHJvY2Vzcy5jCkBAIC02MTEyLDYgKzYxMTIsMTEgQEAgcmVhZF9hbmRfZGlzcG9zZV9v Zl9wcm9jZXNzX291dHB1dCAoc3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqY2hhcnMs CiAJCQkJICAgIHNzaXplX3QgbmJ5dGVzLAogCQkJCSAgICBzdHJ1Y3QgY29kaW5nX3N5c3Rl bSAqY29kaW5nKTsKIAorc3RhdGljIHZvaWQKK3JlYWRfYW5kX2luc2VydF9wcm9jZXNzX291 dHB1dCAoc3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqYnVmLAorCQkJCSAgICBzc2l6 ZV90IG5yZWFkLAorCQkJCXN0cnVjdCBjb2Rpbmdfc3lzdGVtICpwcm9jZXNzX2NvZGluZyk7 CisKIC8qIFJlYWQgcGVuZGluZyBvdXRwdXQgZnJvbSB0aGUgcHJvY2VzcyBjaGFubmVsLAog ICAgc3RhcnRpbmcgd2l0aCBvdXIgYnVmZmVyZWQtYWhlYWQgY2hhcmFjdGVyIGlmIHdlIGhh dmUgb25lLgogICAgWWllbGQgbnVtYmVyIG9mIGRlY29kZWQgY2hhcmFjdGVycyByZWFkLApA QCAtNjIyNyw3ICs2MjMyLDExIEBAIHJlYWRfcHJvY2Vzc19vdXRwdXQgKExpc3BfT2JqZWN0 IHByb2MsIGludCBjaGFubmVsKQogICAgICBmcmllbmRzIGRvbid0IGV4cGVjdCBjdXJyZW50 LWJ1ZmZlciB0byBiZSBjaGFuZ2VkIGZyb20gdW5kZXIgdGhlbS4gICovCiAgIHJlY29yZF91 bndpbmRfY3VycmVudF9idWZmZXIgKCk7CiAKLSAgcmVhZF9hbmRfZGlzcG9zZV9vZl9wcm9j ZXNzX291dHB1dCAocCwgY2hhcnMsIG5ieXRlcywgY29kaW5nKTsKKyAgaWYgKHJlYWRfcHJv Y2Vzc19vdXRwdXRfZmFzdCAmJgorICAgICAgRVEgKHAtPmZpbHRlciwgUWludGVybmFsX2Rl ZmF1bHRfcHJvY2Vzc19maWx0ZXIpKQorICAgIHJlYWRfYW5kX2luc2VydF9wcm9jZXNzX291 dHB1dCAocCwgY2hhcnMsIG5ieXRlcywgY29kaW5nKTsKKyAgZWxzZQorICAgIHJlYWRfYW5k X2Rpc3Bvc2Vfb2ZfcHJvY2Vzc19vdXRwdXQgKHAsIGNoYXJzLCBuYnl0ZXMsIGNvZGluZyk7 CiAKICAgLyogSGFuZGxpbmcgdGhlIHByb2Nlc3Mgb3V0cHV0IHNob3VsZCBub3QgZGVhY3Rp dmF0ZSB0aGUgbWFyay4gICovCiAgIFZkZWFjdGl2YXRlX21hcmsgPSBvZGVhY3RpdmF0ZTsK QEAgLTYyMzYsNiArNjI0NSwxMjggQEAgcmVhZF9wcm9jZXNzX291dHB1dCAoTGlzcF9PYmpl Y3QgcHJvYywgaW50IGNoYW5uZWwpCiAgIHJldHVybiBuYnl0ZXM7CiB9CiAKK3N0YXRpYyB2 b2lkCityZWFkX3Byb2Nlc3Nfb3V0cHV0X2JlZm9yZV9pbnNlcnQgKHN0cnVjdCBMaXNwX1By b2Nlc3MgKnAsIExpc3BfT2JqZWN0ICpvbGRfcmVhZF9vbmx5LAorCQkJCSAgIHB0cmRpZmZf dCAqb2xkX2JlZ3YsIHB0cmRpZmZfdCAqb2xkX3p2LAorCQkJCSAgIHB0cmRpZmZfdCAqYmVm b3JlLCBwdHJkaWZmX3QgKmJlZm9yZV9ieXRlLAorCQkJCSAgIHB0cmRpZmZfdCAqb3BvaW50 LCBwdHJkaWZmX3QgKm9wb2ludF9ieXRlKQoreworICBGc2V0X2J1ZmZlciAocC0+YnVmZmVy KTsKKyAgKm9wb2ludCA9IFBUOworICAqb3BvaW50X2J5dGUgPSBQVF9CWVRFOworICAqb2xk X3JlYWRfb25seSA9IEJWQVIgKGN1cnJlbnRfYnVmZmVyLCByZWFkX29ubHkpOworICAqb2xk X2JlZ3YgPSBCRUdWOworICAqb2xkX3p2ID0gWlY7CisKKyAgYnNldF9yZWFkX29ubHkgKGN1 cnJlbnRfYnVmZmVyLCBRbmlsKTsKKworICAvKiBJbnNlcnQgbmV3IG91dHB1dCBpbnRvIGJ1 ZmZlciBhdCB0aGUgY3VycmVudCBlbmQtb2Ytb3V0cHV0CisgICAgIG1hcmtlciwgdGh1cyBw cmVzZXJ2aW5nIGxvZ2ljYWwgb3JkZXJpbmcgb2YgaW5wdXQgYW5kIG91dHB1dC4gICovCisg IGlmIChYTUFSS0VSIChwLT5tYXJrKS0+YnVmZmVyKQorICAgIHNldF9wb2ludF9mcm9tX21h cmtlciAocC0+bWFyayk7CisgIGVsc2UKKyAgICBTRVRfUFRfQk9USCAoWlYsIFpWX0JZVEUp OworICAqYmVmb3JlID0gUFQ7CisgICpiZWZvcmVfYnl0ZSA9IFBUX0JZVEU7CisKKyAgLyog SWYgdGhlIG91dHB1dCBtYXJrZXIgaXMgb3V0c2lkZSBvZiB0aGUgdmlzaWJsZSByZWdpb24s IHNhdmUKKyAgICAgdGhlIHJlc3RyaWN0aW9uIGFuZCB3aWRlbi4gICovCisgIGlmICghIChC RUdWIDw9IFBUICYmIFBUIDw9IFpWKSkKKyAgICBGd2lkZW4gKCk7Cit9CisKK3N0YXRpYyB2 b2lkCityZWFkX3Byb2Nlc3Nfb3V0cHV0X2FmdGVyX2luc2VydCAoc3RydWN0IExpc3BfUHJv Y2VzcyAqcCwgTGlzcF9PYmplY3QgKm9sZF9yZWFkX29ubHksCisJCQkJICBwdHJkaWZmX3Qg b2xkX2JlZ3YsIHB0cmRpZmZfdCBvbGRfenYsCisJCQkJICBwdHJkaWZmX3QgYmVmb3JlLCBw dHJkaWZmX3QgYmVmb3JlX2J5dGUsCisJCQkJICBwdHJkaWZmX3Qgb3BvaW50LCBwdHJkaWZm X3Qgb3BvaW50X2J5dGUpCit7CisgIHN0cnVjdCBidWZmZXIgKmI7CisKKyAgLyogTWFrZSBz dXJlIHRoZSBwcm9jZXNzIG1hcmtlcidzIHBvc2l0aW9uIGlzIHZhbGlkIHdoZW4gdGhlCisg ICAgIHByb2Nlc3MgYnVmZmVyIGlzIGNoYW5nZWQgaW4gdGhlIHNpZ25hbF9hZnRlcl9jaGFu Z2UgYWJvdmUuCisgICAgIFczIGlzIGtub3duIHRvIGRvIHRoYXQuICAqLworICBpZiAoQlVG RkVSUCAocC0+YnVmZmVyKQorICAgICAgJiYgKGIgPSBYQlVGRkVSIChwLT5idWZmZXIpLCBi ICE9IGN1cnJlbnRfYnVmZmVyKSkKKyAgICBzZXRfbWFya2VyX2JvdGggKHAtPm1hcmssIHAt PmJ1ZmZlciwgQlVGX1BUIChiKSwgQlVGX1BUX0JZVEUgKGIpKTsKKyAgZWxzZQorICAgIHNl dF9tYXJrZXJfYm90aCAocC0+bWFyaywgcC0+YnVmZmVyLCBQVCwgUFRfQllURSk7CisKKyAg dXBkYXRlX21vZGVfbGluZXMgPSAyMzsKKworICAvKiBNYWtlIHN1cmUgb3BvaW50IGFuZCB0 aGUgb2xkIHJlc3RyaWN0aW9ucworICAgICBmbG9hdCBhaGVhZCBvZiBhbnkgbmV3IHRleHQg anVzdCBhcyBwb2ludCB3b3VsZC4gICovCisgIGlmIChvcG9pbnQgPj0gYmVmb3JlKQorICAg IHsKKyAgICAgIG9wb2ludCArPSBQVCAtIGJlZm9yZTsKKyAgICAgIG9wb2ludF9ieXRlICs9 IFBUX0JZVEUgLSBiZWZvcmVfYnl0ZTsKKyAgICB9CisgIGlmIChvbGRfYmVndiA+IGJlZm9y ZSkKKyAgICBvbGRfYmVndiArPSBQVCAtIGJlZm9yZTsKKyAgaWYgKG9sZF96diA+PSBiZWZv cmUpCisgICAgb2xkX3p2ICs9IFBUIC0gYmVmb3JlOworCisgIC8qIElmIHRoZSByZXN0cmlj dGlvbiBpc24ndCB3aGF0IGl0IHNob3VsZCBiZSwgc2V0IGl0LiAgKi8KKyAgaWYgKG9sZF9i ZWd2ICE9IEJFR1YgfHwgb2xkX3p2ICE9IFpWKQorICAgIEZuYXJyb3dfdG9fcmVnaW9uICht YWtlX2ZpeG51bSAob2xkX2JlZ3YpLCBtYWtlX2ZpeG51bSAob2xkX3p2KSk7CisKKyAgYnNl dF9yZWFkX29ubHkgKGN1cnJlbnRfYnVmZmVyLCAqb2xkX3JlYWRfb25seSk7CisgIFNFVF9Q VF9CT1RIIChvcG9pbnQsIG9wb2ludF9ieXRlKTsKK30KKworc3RhdGljIHZvaWQgcmVhZF9h bmRfaW5zZXJ0X3Byb2Nlc3Nfb3V0cHV0IChzdHJ1Y3QgTGlzcF9Qcm9jZXNzICpwLCBjaGFy ICpidWYsCisJCQkJICAgIHNzaXplX3QgbnJlYWQsCisJCQkJICAgIHN0cnVjdCBjb2Rpbmdf c3lzdGVtICpwcm9jZXNzX2NvZGluZykKK3sKKyAgaWYgKCFucmVhZCB8fCBOSUxQIChwLT5i dWZmZXIpIHx8ICFCVUZGRVJfTElWRV9QIChYQlVGRkVSIChwLT5idWZmZXIpKSkKKyAgICBy ZXR1cm47CisKKyAgTGlzcF9PYmplY3Qgb2xkX3JlYWRfb25seTsKKyAgcHRyZGlmZl90IG9s ZF9iZWd2LCBvbGRfenY7CisgIHB0cmRpZmZfdCBiZWZvcmUsIGJlZm9yZV9ieXRlOworICBw dHJkaWZmX3Qgb3BvaW50LCBvcG9pbnRfYnl0ZTsKKworICByZWFkX3Byb2Nlc3Nfb3V0cHV0 X2JlZm9yZV9pbnNlcnQgKHAsICZvbGRfcmVhZF9vbmx5LCAmb2xkX2JlZ3YsICZvbGRfenYs CisJCQkJICAgICAmYmVmb3JlLCAmYmVmb3JlX2J5dGUsICZvcG9pbnQsICZvcG9pbnRfYnl0 ZSk7CisKKyAgLyogQWRhcHRlZCBmcm9tIGNhbGxfcHJvY2Vzcy4gICovCisgIGlmIChOSUxQ IChCVkFSIChYQlVGRkVSKHAtPmJ1ZmZlciksIGVuYWJsZV9tdWx0aWJ5dGVfY2hhcmFjdGVy cykpCisJICAgJiYgISBDT0RJTkdfTUFZX1JFUVVJUkVfREVDT0RJTkcgKHByb2Nlc3NfY29k aW5nKSkKKyAgICB7CisgICAgICBpbnNlcnRfMV9ib3RoIChidWYsIG5yZWFkLCBucmVhZCwg MCwgMCwgMCk7CisgICAgICBzaWduYWxfYWZ0ZXJfY2hhbmdlIChQVCAtIG5yZWFkLCAwLCBu cmVhZCk7CisgICAgfQorICBlbHNlCisgICAgewkJCS8qIFdlIGhhdmUgdG8gZGVjb2RlIHRo ZSBpbnB1dC4gICovCisgICAgICBMaXNwX09iamVjdCBjdXJidWY7CisgICAgICBpbnQgY2Fy cnlvdmVyID0gMDsKKyAgICAgIHNwZWNwZGxfcmVmIGNvdW50MSA9IFNQRUNQRExfSU5ERVgg KCk7CisKKyAgICAgIFhTRVRCVUZGRVIgKGN1cmJ1ZiwgY3VycmVudF9idWZmZXIpOworICAg ICAgLyogV2UgY2Fubm90IGFsbG93IGFmdGVyLWNoYW5nZS1mdW5jdGlvbnMgYmUgcnVuCisJ IGR1cmluZyBkZWNvZGluZywgYmVjYXVzZSB0aGF0IG1pZ2h0IG1vZGlmeSB0aGUKKwkgYnVm ZmVyLCB3aGlsZSB3ZSByZWx5IG9uIHByb2Nlc3NfY29kaW5nLnByb2R1Y2VkIHRvCisJIGZh aXRoZnVsbHkgcmVmbGVjdCBpbnNlcnRlZCB0ZXh0IHVudGlsIHdlCisJIFRFTVBfU0VUX1BU X0JPVEggYmVsb3cuICAqLworICAgICAgc3BlY2JpbmQgKFFpbmhpYml0X21vZGlmaWNhdGlv bl9ob29rcywgUXQpOworICAgICAgZGVjb2RlX2NvZGluZ19jX3N0cmluZyAocHJvY2Vzc19j b2RpbmcsCisJCQkgICAgICAodW5zaWduZWQgY2hhciAqKSBidWYsIG5yZWFkLCBjdXJidWYp OworICAgICAgdW5iaW5kX3RvIChjb3VudDEsIFFuaWwpOworCisgICAgICBURU1QX1NFVF9Q VF9CT1RIIChQVCArIHByb2Nlc3NfY29kaW5nLT5wcm9kdWNlZF9jaGFyLAorCQkJUFRfQllU RSArIHByb2Nlc3NfY29kaW5nLT5wcm9kdWNlZCk7CisgICAgICBzaWduYWxfYWZ0ZXJfY2hh bmdlIChQVCAtIHByb2Nlc3NfY29kaW5nLT5wcm9kdWNlZF9jaGFyLAorCQkJICAgMCwgcHJv Y2Vzc19jb2RpbmctPnByb2R1Y2VkX2NoYXIpOworICAgICAgY2FycnlvdmVyID0gcHJvY2Vz c19jb2RpbmctPmNhcnJ5b3Zlcl9ieXRlczsKKyAgICAgIGlmIChjYXJyeW92ZXIgPiAwKQor CW1lbWNweSAoYnVmLCBwcm9jZXNzX2NvZGluZy0+Y2FycnlvdmVyLAorCQlwcm9jZXNzX2Nv ZGluZy0+Y2FycnlvdmVyX2J5dGVzKTsKKyAgICB9CisKKyAgcmVhZF9wcm9jZXNzX291dHB1 dF9hZnRlcl9pbnNlcnQgKHAsICZvbGRfcmVhZF9vbmx5LCBvbGRfYmVndiwgb2xkX3p2LAor CQkJCSAgICBiZWZvcmUsIGJlZm9yZV9ieXRlLCBvcG9pbnQsIG9wb2ludF9ieXRlKTsKK30K Kwogc3RhdGljIHZvaWQKIHJlYWRfYW5kX2Rpc3Bvc2Vfb2ZfcHJvY2Vzc19vdXRwdXQgKHN0 cnVjdCBMaXNwX1Byb2Nlc3MgKnAsIGNoYXIgKmNoYXJzLAogCQkJCSAgICBzc2l6ZV90IG5i eXRlcywKQEAgLTYzMzksNyArNjQ3MCw2IEBAIERFRlVOICgiaW50ZXJuYWwtZGVmYXVsdC1w cm9jZXNzLWZpbHRlciIsIEZpbnRlcm5hbF9kZWZhdWx0X3Byb2Nlc3NfZmlsdGVyLAogICAo TGlzcF9PYmplY3QgcHJvYywgTGlzcF9PYmplY3QgdGV4dCkKIHsKICAgc3RydWN0IExpc3Bf UHJvY2VzcyAqcDsKLSAgcHRyZGlmZl90IG9wb2ludDsKIAogICBDSEVDS19QUk9DRVNTIChw cm9jKTsKICAgcCA9IFhQUk9DRVNTIChwcm9jKTsKQEAgLTYzNTAsMzEgKzY0ODAsMTAgQEAg REVGVU4gKCJpbnRlcm5hbC1kZWZhdWx0LXByb2Nlc3MtZmlsdGVyIiwgRmludGVybmFsX2Rl ZmF1bHRfcHJvY2Vzc19maWx0ZXIsCiAgICAgICBMaXNwX09iamVjdCBvbGRfcmVhZF9vbmx5 OwogICAgICAgcHRyZGlmZl90IG9sZF9iZWd2LCBvbGRfenY7CiAgICAgICBwdHJkaWZmX3Qg YmVmb3JlLCBiZWZvcmVfYnl0ZTsKLSAgICAgIHB0cmRpZmZfdCBvcG9pbnRfYnl0ZTsKLSAg ICAgIHN0cnVjdCBidWZmZXIgKmI7Ci0KLSAgICAgIEZzZXRfYnVmZmVyIChwLT5idWZmZXIp OwotICAgICAgb3BvaW50ID0gUFQ7Ci0gICAgICBvcG9pbnRfYnl0ZSA9IFBUX0JZVEU7Ci0g ICAgICBvbGRfcmVhZF9vbmx5ID0gQlZBUiAoY3VycmVudF9idWZmZXIsIHJlYWRfb25seSk7 Ci0gICAgICBvbGRfYmVndiA9IEJFR1Y7Ci0gICAgICBvbGRfenYgPSBaVjsKLQotICAgICAg YnNldF9yZWFkX29ubHkgKGN1cnJlbnRfYnVmZmVyLCBRbmlsKTsKLQotICAgICAgLyogSW5z ZXJ0IG5ldyBvdXRwdXQgaW50byBidWZmZXIgYXQgdGhlIGN1cnJlbnQgZW5kLW9mLW91dHB1 dAotCSBtYXJrZXIsIHRodXMgcHJlc2VydmluZyBsb2dpY2FsIG9yZGVyaW5nIG9mIGlucHV0 IGFuZCBvdXRwdXQuICAqLwotICAgICAgaWYgKFhNQVJLRVIgKHAtPm1hcmspLT5idWZmZXIp Ci0Jc2V0X3BvaW50X2Zyb21fbWFya2VyIChwLT5tYXJrKTsKLSAgICAgIGVsc2UKLQlTRVRf UFRfQk9USCAoWlYsIFpWX0JZVEUpOwotICAgICAgYmVmb3JlID0gUFQ7Ci0gICAgICBiZWZv cmVfYnl0ZSA9IFBUX0JZVEU7CisgICAgICBwdHJkaWZmX3Qgb3BvaW50LCBvcG9pbnRfYnl0 ZTsKIAotICAgICAgLyogSWYgdGhlIG91dHB1dCBtYXJrZXIgaXMgb3V0c2lkZSBvZiB0aGUg dmlzaWJsZSByZWdpb24sIHNhdmUKLQkgdGhlIHJlc3RyaWN0aW9uIGFuZCB3aWRlbi4gICov Ci0gICAgICBpZiAoISAoQkVHViA8PSBQVCAmJiBQVCA8PSBaVikpCi0JRndpZGVuICgpOwor ICAgICAgcmVhZF9wcm9jZXNzX291dHB1dF9iZWZvcmVfaW5zZXJ0IChwLCAmb2xkX3JlYWRf b25seSwgJm9sZF9iZWd2LCAmb2xkX3p2LAorCQkJCQkgJmJlZm9yZSwgJmJlZm9yZV9ieXRl LCAmb3BvaW50LCAmb3BvaW50X2J5dGUpOwogCiAgICAgICAvKiBBZGp1c3QgdGhlIG11bHRp Ynl0ZW5lc3Mgb2YgVEVYVCB0byB0aGF0IG9mIHRoZSBidWZmZXIuICAqLwogICAgICAgaWYg KE5JTFAgKEJWQVIgKGN1cnJlbnRfYnVmZmVyLCBlbmFibGVfbXVsdGlieXRlX2NoYXJhY3Rl cnMpKQpAQCAtNjM4NywzNSArNjQ5Niw4IEBAIERFRlVOICgiaW50ZXJuYWwtZGVmYXVsdC1w cm9jZXNzLWZpbHRlciIsIEZpbnRlcm5hbF9kZWZhdWx0X3Byb2Nlc3NfZmlsdGVyLAogICAg ICAgaW5zZXJ0X2Zyb21fc3RyaW5nX2JlZm9yZV9tYXJrZXJzICh0ZXh0LCAwLCAwLAogCQkJ CQkgU0NIQVJTICh0ZXh0KSwgU0JZVEVTICh0ZXh0KSwgMCk7CiAKLSAgICAgIC8qIE1ha2Ug c3VyZSB0aGUgcHJvY2VzcyBtYXJrZXIncyBwb3NpdGlvbiBpcyB2YWxpZCB3aGVuIHRoZQot CSBwcm9jZXNzIGJ1ZmZlciBpcyBjaGFuZ2VkIGluIHRoZSBzaWduYWxfYWZ0ZXJfY2hhbmdl IGFib3ZlLgotCSBXMyBpcyBrbm93biB0byBkbyB0aGF0LiAgKi8KLSAgICAgIGlmIChCVUZG RVJQIChwLT5idWZmZXIpCi0JICAmJiAoYiA9IFhCVUZGRVIgKHAtPmJ1ZmZlciksIGIgIT0g Y3VycmVudF9idWZmZXIpKQotCXNldF9tYXJrZXJfYm90aCAocC0+bWFyaywgcC0+YnVmZmVy LCBCVUZfUFQgKGIpLCBCVUZfUFRfQllURSAoYikpOwotICAgICAgZWxzZQotCXNldF9tYXJr ZXJfYm90aCAocC0+bWFyaywgcC0+YnVmZmVyLCBQVCwgUFRfQllURSk7Ci0KLSAgICAgIHVw ZGF0ZV9tb2RlX2xpbmVzID0gMjM7Ci0KLSAgICAgIC8qIE1ha2Ugc3VyZSBvcG9pbnQgYW5k IHRoZSBvbGQgcmVzdHJpY3Rpb25zCi0JIGZsb2F0IGFoZWFkIG9mIGFueSBuZXcgdGV4dCBq dXN0IGFzIHBvaW50IHdvdWxkLiAgKi8KLSAgICAgIGlmIChvcG9pbnQgPj0gYmVmb3JlKQot CXsKLQkgIG9wb2ludCArPSBQVCAtIGJlZm9yZTsKLQkgIG9wb2ludF9ieXRlICs9IFBUX0JZ VEUgLSBiZWZvcmVfYnl0ZTsKLQl9Ci0gICAgICBpZiAob2xkX2JlZ3YgPiBiZWZvcmUpCi0J b2xkX2JlZ3YgKz0gUFQgLSBiZWZvcmU7Ci0gICAgICBpZiAob2xkX3p2ID49IGJlZm9yZSkK LQlvbGRfenYgKz0gUFQgLSBiZWZvcmU7Ci0KLSAgICAgIC8qIElmIHRoZSByZXN0cmljdGlv biBpc24ndCB3aGF0IGl0IHNob3VsZCBiZSwgc2V0IGl0LiAgKi8KLSAgICAgIGlmIChvbGRf YmVndiAhPSBCRUdWIHx8IG9sZF96diAhPSBaVikKLQlGbmFycm93X3RvX3JlZ2lvbiAobWFr ZV9maXhudW0gKG9sZF9iZWd2KSwgbWFrZV9maXhudW0gKG9sZF96dikpOwotCi0gICAgICBi c2V0X3JlYWRfb25seSAoY3VycmVudF9idWZmZXIsIG9sZF9yZWFkX29ubHkpOwotICAgICAg U0VUX1BUX0JPVEggKG9wb2ludCwgb3BvaW50X2J5dGUpOworICAgICAgcmVhZF9wcm9jZXNz X291dHB1dF9hZnRlcl9pbnNlcnQgKHAsICZvbGRfcmVhZF9vbmx5LCBvbGRfYmVndiwgb2xk X3p2LAorCQkJCQliZWZvcmUsIGJlZm9yZV9ieXRlLCBvcG9pbnQsIG9wb2ludF9ieXRlKTsK ICAgICB9CiAgIHJldHVybiBRbmlsOwogfQpAQCAtODc0MCw2ICs4ODIyLDEzIEBAIHN5bXNf b2ZfcHJvY2VzcyAodm9pZCkKIC9wcm9jL3N5cy9mcy9waXBlLW1heC1zaXplLiAgU2VlIHBp cGUoNykgbWFucGFnZSBmb3IgZGV0YWlscy4gICovKTsKICAgcmVhZF9wcm9jZXNzX291dHB1 dF9tYXggPSA0MDk2OwogCisgIERFRlZBUl9CT09MICgicmVhZC1wcm9jZXNzLW91dHB1dC1m YXN0IiwgcmVhZF9wcm9jZXNzX291dHB1dF9mYXN0LAorCSAgICAgICBkb2M6IC8qIE5vbi1u aWwgdG8gb3B0aW1pemUgdGhlIGluc2VydGlvbiBvZiBwcm9jZXNzIG91dHB1dC4KK1dlIHNr aXAgY2FsbGluZyBgaW50ZXJuYWwtZGVmYXVsdC1wcm9jZXNzLWZpbHRlcicgYW5kIGRvbid0 IGFsbG9jYXRlCit0aGUgTGlzcCBzdHJpbmcgdGhhdCB3b3VsZCBiZSB1c2VkIGFzIGl0cyBh cmd1bWVudC4gIE9ubHkgYWZmZWN0cyB0aGUKK2Nhc2Ugb2YgYXN5bmNocm9ub3VzIHByb2Nl c3Mgd2l0aCB0aGUgZGVmYXVsdCBmaWx0ZXIuICAqLyk7CisgIHJlYWRfcHJvY2Vzc19vdXRw dXRfZmFzdCA9IFF0OworCiAgIERFRlZBUl9JTlQgKCJwcm9jZXNzLWVycm9yLXBhdXNlLXRp bWUiLCBwcm9jZXNzX2Vycm9yX3BhdXNlX3RpbWUsCiAJICAgICAgZG9jOiAvKiBUaGUgbnVt YmVyIG9mIHNlY29uZHMgdG8gcGF1c2UgYWZ0ZXIgaGFuZGxpbmcgcHJvY2VzcyBlcnJvcnMu CiBUaGlzIGlzbid0IHVzZWQgZm9yIGFsbCBwcm9jZXNzLXJlbGF0ZWQgZXJyb3JzLCBidXQg aXMgdXNlZCB3aGVuIGEK --------------ujujwY71SxzZu4tHORIFXUna-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 18 18:51:43 2023 Received: (at control) by debbugs.gnu.org; 18 Sep 2023 22:51:43 +0000 Received: from localhost ([127.0.0.1]:54900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiN5j-0004k7-Ef for submit@debbugs.gnu.org; Mon, 18 Sep 2023 18:51:43 -0400 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:62912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiN5g-0004jq-12 for control@debbugs.gnu.org; Mon, 18 Sep 2023 18:51:42 -0400 Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2bff936e10fso23721091fa.1 for ; Mon, 18 Sep 2023 15:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695077485; x=1695682285; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=lesQzPRtbTnj5ILsG5k+KOPISEcVKsO4wq0i1wRNaNI=; b=B9nOufqqaXCH1kYlPnw/zCwhhF07dly6XVQMOZDkCD59AbpolacJeVN3KgPsMmB0rr Tmozhtior2a+NWkaBTP51iXK1zKrqzZ8DYPoSI7OCPuE8VduEvdBKnc2Mls35DJNNod7 0XxWGohS6e7dqpga5euAfWiwHCdAtccG34CdLw8QIi2xkESUFy1rkvXeJ0V1WU8eWDpL P4MmRzZrUb9F+t1UgT0TcKvxp0i7mxZtN3SNz95Zups7NmnWszy39t5c+7Vw2jFif7Gv 0d3Kgm8Om6PwyngKYQ4QKNvFEBUCCQIkSfYKPSK0aUc6HHXervpkcg9NwMpP7ZujPrhg xiMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695077485; x=1695682285; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lesQzPRtbTnj5ILsG5k+KOPISEcVKsO4wq0i1wRNaNI=; b=F99kB5jgfiDBDe9SQf+FA/1A/+hDNCIFcM7NF1QC7fFJokV1/XLmoY91nzZUyPZBjK bE8CPCC4l19BIrD6Blhi0k1qwuhcPpiDio9nAJGhm8VXPOkDpePv/mSZtJExfuTKN6Nc LK5xDAniIL3t1MBkHgyUeSDnupl/of+J89pdBDnh5Kwgvf3cA47Ji7murH++N9yw/aSl 3Wq+a87QVVStn13r6C18MGV7BTvEeGOFe5zG93GeX64VS8koFpqmsXZwzjfe1+0dqt0/ F11mn89Q5gMIQT1O3+SrFoMnFscXc5GrQ1dv/xQLsrFpsB0M8UK/lJOGtUFYuRwrVPNr cThQ== X-Gm-Message-State: AOJu0YylPxidOF7nTrb+NxBNZIdzgTJZzPJGsmXnIEX78ZEMPF8IuuEF f2itIMI1G+/Qcg6RUdOobY3gGiWi8ODAQyibcevmNsL/ X-Google-Smtp-Source: AGHT+IFn0f5pTp3kXdaM6R7gRNccennZwFOJ65jKeCJy+QsOEfpUXJv+IgF3UG4twW1so6aBwUQXfz6gYK2mQhFIngQ= X-Received: by 2002:a2e:890a:0:b0:2bb:c19b:710c with SMTP id d10-20020a2e890a000000b002bbc19b710cmr405029lji.5.1695077485573; Mon, 18 Sep 2023 15:51:25 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 18 Sep 2023 15:51:25 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Mon, 18 Sep 2023 15:51:25 -0700 Message-ID: Subject: control message for bug #66020 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 66020 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 19 16:00:06 2023 Received: (at 66020) by debbugs.gnu.org; 19 Sep 2023 20:00:06 +0000 Received: from localhost ([127.0.0.1]:57855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qigtB-0000vY-Fk for submit@debbugs.gnu.org; Tue, 19 Sep 2023 16:00:06 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:58893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qigt8-0000uT-Ns for 66020@debbugs.gnu.org; Tue, 19 Sep 2023 16:00:04 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3DD6D5C01AA; Tue, 19 Sep 2023 15:59:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 19 Sep 2023 15:59:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695153588; x=1695239988; bh=O2MS+YZGx/qBn4Xj9GVu4SjO0x3m8JC4VSs qXXmB7Ck=; b=hhuHbUXTvbhwUloJ4wyqHiBXkPI9oLZ4vL35zZ4h6s/MaZ6fXQO YqJt+D69oAYdfWbJV5o+Jd3o48JpixdF3sUa/8R7Th7jsy0z9IYbFxscGnP0RW3H 1CDUQizlw02z1Etfm9mbS1YlVGgUIcuTc3uxVrj+XTwQifUs0y9daacIsKuI/abx ga0er+M3Re8BB0QNDZIyMcv1rtgm3HOSHQ5nY4bmuFI/iTxFzqOFGrb9Ko4gbvW7 m+P7PUcRQtA8Vtu9PMVZYdjH7xzGU9vBljHKOvza3mRPBlV7f+EDHz+8760x+VUW fyiapAm+yDdXCr8f0vQjUS5wMnqvptAek4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695153588; x=1695239988; bh=O2MS+YZGx/qBn4Xj9GVu4SjO0x3m8JC4VSs qXXmB7Ck=; b=N7A+A7p5uchSAYMz6ojNh61/irnuk2xF62Bj0T96C0dyFQ1zGlJ uA3J24/zDBPxRPBg/mZFeUM891+WGWoub7XsEB9vG50ucj+9aYot/96ivaK5PiOK fHgKNaMeQ/MGX9jQllrOLLpqbYlRrOM1NFF4v1/ei1eUeck45sKR8P7BHjFCGw0c Lm5bv4MrLZoumZq+dULA3dIcCY7ie8jxwhyQfpE3dO/rlHggfQnzW6kz6k/gI+uE TMsQck/JuyyLz0nyTHVgSuraC60wu3Khk5VrFzMrvLMhiATPBzlZyA2cQ9KCoYVG o00uH+5/F6yhUzhsxlQUAuu0Ssh/Fnar5zw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekuddguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Sep 2023 15:59:47 -0400 (EDT) Message-ID: <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> Date: Tue, 19 Sep 2023 22:59:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii References: <35f8b664-0241-9f96-1aa0-20ca51b2d34c@gutov.dev> <59c30342-a7e0-d83b-a128-0faae4cbd633@gutov.dev> <83pm4bi6qa.fsf@gnu.org> <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83a5tmk79p.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is another continuation from bug#64735, a subthread in this bug seems more fitting, given that I did most of the tests with its patch applied. On 16/09/2023 08:37, Eli Zaretskii wrote: >> Date: Sat, 16 Sep 2023 04:32:26 +0300 >> Cc:luangruo@yahoo.com,sbaugh@janestreet.com,yantar92@posteo.net, >> 64735@debbugs.gnu.org >> From: Dmitry Gutov >> >>>> I wonder what scenario that might become apparent in. Launching many >>>> small processes at once? Can't think of a realistic test case. >>> One process suffices. The effect might not be significant, but >>> slowdowns due to new features are generally considered regressions. >> We'd need some objective way to evaluate this. Otherwise we'd just stop >> at the prospect of slowing down some process somewhere by 9ns (never >> mind speeding others up). > That could indeed happen, and did happen in other cases. My personal > conclusion from similar situations is that it is impossible to tell in > advance what the reaction will be; we need to present the numbers and > see how the chips fall. I wrote this test: (defun test-ls-output () (with-temp-buffer (let ((proc (make-process :name "ls" :sentinel (lambda (&rest _)) :buffer (current-buffer) :stderr (current-buffer) :connection-type 'pipe :command '("ls")))) (while (accept-process-output proc)) (buffer-string)))) And tried to find some case where the difference is the least in favor of high buffer length. The one in favor of it we already know (a process with lots and lots of output). But when running 'ls' on a small directory (output 500 chars long), the variance in benchmarking is larger than any difference I can see from changing read-process-output-max from 4096 to 40960 (or to 40900 even). The benchmark is the following: (benchmark 1000 '(let ((read-process-output-fast t) (read-process-output-max 4096)) (test-ls-output))) When the directory is a little large (output ~50000 chars), there is more nuance. At first, as long as (!) read_and_insert_process_output_v2 patch is applied and read-process-output-fast is non-nil, the difference is negligible: | read-process-output-max | bench result | | 4096 | (4.566418994 28 0.8000380139999992) | | 40960 | (4.640526664 32 0.8330555910000008) | | 409600 | (4.629948652 30 0.7989731299999994) | For completeness, here are the same results for read-process-output-fast=nil (emacs-29 is similar, though all a little slower): | read-process-output-max | bench result | | 4096 | (4.953397326 52 1.354643750000001) | | 40960 | (6.942334958 75 2.0616055079999995) | | 409600 | (7.124765651 76 2.0892871070000005) | But as the session gets older (and I repeat these and other memory-intensive benchmarks), the outlay changes, and the larger buffer leads to uniformly worse number (the below is taken with read-process-output-fast=t; with that var set to nil the results were even worse): | read-process-output-max | bench result | | 4096 | (5.02324481 41 0.8851443580000051) | | 40960 | (5.438721274 61 1.2202541989999958) | | 409600 | (6.11188183 77 1.5461468160000038) | ...which seems odd given that in general, the buffer length closer to the length of the output should be preferable, because otherwise it is allocated multiple times, and read_process_output is likewise called more. Perhaps longer strings get more difficult to allocate as fragmentation increases? So, the last table is from a session I had running from yesterday, and the first table was produced after I restarted Emacs about an hour ago (the numbers were stable for 1-2 hours while I was writing this email on-and-off, then started degrading again a little bit, though not yet -- a couple of hours since -- even halfway to the numbers in the last table). Where to go from here? - Maybe we declare the difference insignificant and bump the value of read-process-output-max, given that it helps in other cases, - Or try to find out the cause for degradation, - Or keep the default the same, but make it easier to use different value for different processes (meaning, we resurrect the discussion in bug#38561). From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 20 07:20:31 2023 Received: (at 66020) by debbugs.gnu.org; 20 Sep 2023 11:20:31 +0000 Received: from localhost ([127.0.0.1]:58460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qivFv-0006LO-6T for submit@debbugs.gnu.org; Wed, 20 Sep 2023 07:20:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qivFq-0006L7-Nu for 66020@debbugs.gnu.org; Wed, 20 Sep 2023 07:20:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qivFb-0001vy-Cc; Wed, 20 Sep 2023 07:20:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JP2b9RpeZ7FmPsh83Q1X1ZHL/qBavOYid9XK4OCTkSY=; b=fr4CuHnXW3by iQwFUOl0qnBJ6HpdUTHAuK45KYwoBM2YmjB34whTCwFwrNEphf+R0+06yMZRfa+I+gb7ZSYbRXPly 7TczskzNp5GmvzBP0jWotczCAg0OuQgRB7G027SSyI490krApzz6FrAbmdtU8BvGoY3TSNHzQD8LD M8jAplYmiRWsEoMXValK0egYU4doxIwpe7rlL8k3WDretRg0gPp5c6+yApQ6zSV4elyqUuXtlJfQ4 LeEEgoKy009JpMlzEds/0CRdARSoT6dM121TUdx/tNu6WyPAoPeqp9pyxIQQXXad4aCjgy/Kfhbu0 7cgrjQ0uYJ5qd8wKXuKbpw==; Date: Wed, 20 Sep 2023 14:20:13 +0300 Message-Id: <83zg1hay6q.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov , Stefan Kangas , Stefan Monnier In-Reply-To: <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> (message from Dmitry Gutov on Tue, 19 Sep 2023 22:59:43 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <35f8b664-0241-9f96-1aa0-20ca51b2d34c@gutov.dev> <59c30342-a7e0-d83b-a128-0faae4cbd633@gutov.dev> <83pm4bi6qa.fsf@gnu.org> <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 19 Sep 2023 22:59:43 +0300 > Cc: 66020@debbugs.gnu.org > From: Dmitry Gutov > > - Maybe we declare the difference insignificant and bump the value of > read-process-output-max, given that it helps in other cases, > - Or try to find out the cause for degradation, > - Or keep the default the same, but make it easier to use different > value for different processes (meaning, we resurrect the discussion in > bug#38561). I'd try the same experiment on other use cases, say "M-x grep" and "M-x compile" with large outputs, and if you see the same situation there (i.e. larger buffers are no worse), try increasing the default value on master. Stefan & Stefan: any comments or suggestions? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 20 20:58:06 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 00:58:06 +0000 Received: from localhost ([127.0.0.1]:60677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj817-0004I9-NP for submit@debbugs.gnu.org; Wed, 20 Sep 2023 20:58:06 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:44225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj814-0004Hd-DK for 66020@debbugs.gnu.org; Wed, 20 Sep 2023 20:58:04 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 81A125C01F4; Wed, 20 Sep 2023 20:57:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 20 Sep 2023 20:57:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695257867; x=1695344267; bh=/SMKlPMD5eNouTqIWYRhKVgZZJpXTfFocMz gA4OnJr0=; b=ftTBKGCkWLYaBKyOPxzkdOnaJ13lbR6mt8ThgjMQ7futVjc4LIE 5R5TKmXCG/wROvjVgWSNLP9U6gMTuomAcCxf6/lFgx9tsq1Y4G3EI5nIgeN96jLB XwexGMSG3dP3eaKoX5yRzE7bsxhxOk0iDmt/t98RsjIxxbu2j3oFvSzwpLlCXxye RDNW+vTr6Ejdb8RObOsaqYAEMmb2xTTRwLQpAtgdsM6VhaBB5QzKzuiq2cUjLZyD t6OVNfsr1yUPTvI4FnauoDYfTEmeS0Y0OhHhw6O3hZCEuODW0z+H4PNiomRlOZ0H VnRkPBLJPLo7PHb/qzP+AtF3A3TaZA2h6GA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695257867; x=1695344267; bh=/SMKlPMD5eNouTqIWYRhKVgZZJpXTfFocMz gA4OnJr0=; b=WqcwNG7eeaVzJCSywc7GFMTTb0TJ89dDtS+V4+cnrVcaE1sbUx4 2RJIlnA/qp+m9z3SCh7eHZtDsWPjoueEpb4NDy4uGZs+ihszwi9RYqmQephQzx2z HQDKe1yasrcrhChL864s0LdwVBDyOoevVNl4B+NU0KTcB0WfYUPYJDb/Jfp/Ol9t dahXf6Wm+5jpo6iGUeWCcJ5W7aNtrpmnphSwrDiJRs6r58vH5FTTgxlrWiEN88fN vusjNLbiuypFu/5Da0tNE654r2bqLvm/LCAh8FWPqetFrGCjHMag2RXlULbJrpBy IQ90k4qHbdEmx7kN2QGLF3tTgz6B9o/XSuQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekgedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Sep 2023 20:57:45 -0400 (EDT) Message-ID: <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> Date: Thu, 21 Sep 2023 03:57:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii , Stefan Kangas , Stefan Monnier References: <83pm4bi6qa.fsf@gnu.org> <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83zg1hay6q.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 20/09/2023 14:20, Eli Zaretskii wrote: >> Date: Tue, 19 Sep 2023 22:59:43 +0300 >> Cc: 66020@debbugs.gnu.org >> From: Dmitry Gutov >> >> - Maybe we declare the difference insignificant and bump the value of >> read-process-output-max, given that it helps in other cases, >> - Or try to find out the cause for degradation, >> - Or keep the default the same, but make it easier to use different >> value for different processes (meaning, we resurrect the discussion in >> bug#38561). > > I'd try the same experiment on other use cases, say "M-x grep" and > "M-x compile" with large outputs, and if you see the same situation > there (i.e. larger buffers are no worse), try increasing the default > value on master. I've run one particular rgrep search a few times (24340 hits, ~44s when the variable's value is either 4096 or 409600). And it makes sense that there is no difference: compilation modes do a lot more work than just capturing the process output or splitting it into strings. That leaves the question of what new value to use. 409600 is optimal for a large-output process but seems too much as default anyway (even if I have very little experimental proof for that hesitance: any help with that would be very welcome). I did some more experimenting, though. At a superficial glance, allocating the 'chars' buffer at the beginning of read_process_output is problematic because we could instead reuse a buffer for the whole duration of the process. I tried that (adding a new field to Lisp_Process and setting it in make_process), although I had to use a value produced by make_uninit_string: apparently simply storing a char* field inside a managed structure creates problems for the GC and early segfaults. Anyway, the result was slightly _slower_ than the status quo. So I read what 'alloca' does, and it looks hard to beat. But it's only used (as you of course know) when the value is <= MAX_ALLOCA, which is currently 16384. Perhaps an optimal default value shouldn't exceed this, even if it's hard to create a benchmark that shows a difference. With read-process-output-max set to 16384, my original benchmark gets about halfway to the optimal number. And I think we should make the process "remember" the value at its creation either way (something touched on in bug#38561): in bug#55737 we added an fcntl call to make the larger values take effect. But this call is in create_process: so any subsequent increase to a large value of this var won't have effect. Might as well remember it there (in a new field), then it'll be easier to use different values of it for different processes (set using let-binding at the time of the process' creation). From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 20 22:36:39 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 02:36:39 +0000 Received: from localhost ([127.0.0.1]:60721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj9YV-0006xd-1d for submit@debbugs.gnu.org; Wed, 20 Sep 2023 22:36:39 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj9YS-0006xQ-Nc for 66020@debbugs.gnu.org; Wed, 20 Sep 2023 22:36:37 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 872E0442A6B; Wed, 20 Sep 2023 22:36:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1695263780; bh=VqFa2tYyWljRPjSaoSLlRenp7Xu3q0tg4LMC7uC/yos=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FcH2ZLdpN/zc7IW8uGwtE+Ch7jGsRyRs7TG7L+G53A3OHElEPiPU06MdAewcSiP3H 1/sSWlJNf960tl6I7c2kISdLBmqCDlB5cY+3O8aZkjzncL9wmxhHx2tth+4ZODoF2h DXi11vMV3zRhcX0fF/G4MPQoeei9QYrlbp5tNhTYxLby81n9V2SxD06LKRlR9wqZzm xcfNqn6/ZDCIx4W0ioxuTquMot8i9ZhyKqV/SFXLpHc/1jQz/5+oE1ZOG3IU7i26M3 74Fl/nir+tZOCWA5SMM82pGUwF2G9YD+Rcc21jf8z/Nt/VROoAKxVOlpbHJmCyLNb/ pku4SoRJ9aD9Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 14DAC44214A; Wed, 20 Sep 2023 22:36:20 -0400 (EDT) Received: from pastel (unknown [45.72.220.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DE7901204BB; Wed, 20 Sep 2023 22:36:19 -0400 (EDT) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max In-Reply-To: <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> (Dmitry Gutov's message of "Thu, 21 Sep 2023 03:57:43 +0300") Message-ID: References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> Date: Wed, 20 Sep 2023 22:36:18 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: Eli Zaretskii , Stefan Kangas , 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > make_process), although I had to use a value produced by make_uninit_string: > apparently simply storing a char* field inside a managed structure creates > problems for the GC and early segfaults. Anyway, the result was slightly That should depend on *where* you put that field. Basically, it has to come after: /* The thread a process is linked to, or nil for any thread. */ Lisp_Object thread; /* After this point, there are no Lisp_Objects. */ since all the words up to that point will be traced by the GC (and assumed to be Lisp_Object fields). But of course, if you created the buffer with `make_uninit_string` then it'll be inside the Lisp heap and so it'll be reclaimed if the GC doesn't find any reference to it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 03:42:44 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 07:42:45 +0000 Received: from localhost ([127.0.0.1]:60965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjEKi-0006sx-Ic for submit@debbugs.gnu.org; Thu, 21 Sep 2023 03:42:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjEKf-0006se-Qi for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 03:42:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjEKP-0007R5-Jl; Thu, 21 Sep 2023 03:42:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=w+0GZ/5eXjdtFkS7bVhhktO6ZAl+vYVgjqojSSPvd0k=; b=h72htidNP5Uc kE/RFJOVPAFlRfgDRnkgfHPliQsRXRqwVjv6SMw7zfXP3rkguIMggoJx8CsDtZ1aTh66dcXmSVZIX YUGO4E4y2EeO5gdC2OuirU2+dCmTXQM+qykOZZvAkdCWHVZHAaur1N1Az1l2NARc7KX4y7oKkR+ku 273bvCk4dwujxqRzU9a/uoVrJVHEw72ENFQdskl38kaehT5TiJhSjpakPnCRO9gwizwidZg5evUMy 1cjfnsuitPYqWJTs3/0XZXXD+uyEGu8IU3j8qr4Z+XyUN7uc4UU4AKe9AQjL29MuR8Ko+gr3Ig7vQ gWBIRhz0jqj0c4OhvNxlKw==; Date: Thu, 21 Sep 2023 10:42:31 +0300 Message-Id: <83led09dlk.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> (message from Dmitry Gutov on Thu, 21 Sep 2023 03:57:43 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <83pm4bi6qa.fsf@gnu.org> <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 03:57:43 +0300 > Cc: 66020@debbugs.gnu.org > From: Dmitry Gutov > > That leaves the question of what new value to use. 409600 is optimal for > a large-output process but seems too much as default anyway (even if I > have very little experimental proof for that hesitance: any help with > that would be very welcome). How does the throughput depend on this value? If the dependence curve plateaus at some lower value, we could use that lower value as a "good-enough" default. > I did some more experimenting, though. At a superficial glance, > allocating the 'chars' buffer at the beginning of read_process_output is > problematic because we could instead reuse a buffer for the whole > duration of the process. I tried that (adding a new field to > Lisp_Process and setting it in make_process), although I had to use a > value produced by make_uninit_string: apparently simply storing a char* > field inside a managed structure creates problems for the GC and early > segfaults. Anyway, the result was slightly _slower_ than the status quo. > > So I read what 'alloca' does, and it looks hard to beat. But it's only > used (as you of course know) when the value is <= MAX_ALLOCA, which is > currently 16384. Perhaps an optimal default value shouldn't exceed this, > even if it's hard to create a benchmark that shows a difference. With > read-process-output-max set to 16384, my original benchmark gets about > halfway to the optimal number. Which I think means we should stop worrying about the overhead of malloc for this purpose, as it is fast enough, at least on GNU/Linux. > And I think we should make the process "remember" the value at its > creation either way (something touched on in bug#38561): in bug#55737 we > added an fcntl call to make the larger values take effect. But this call > is in create_process: so any subsequent increase to a large value of > this var won't have effect. Why would the variable change after create_process? I'm afraid I don't understand what issue you are trying to deal with here. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 04:08:00 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 08:08:00 +0000 Received: from localhost ([127.0.0.1]:32784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjEj0-0007cz-RV for submit@debbugs.gnu.org; Thu, 21 Sep 2023 04:08:00 -0400 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:45255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjEiw-0007ci-FF for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 04:07:49 -0400 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c12ae20a5cso9720891fa.2 for <66020@debbugs.gnu.org>; Thu, 21 Sep 2023 01:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695283650; x=1695888450; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=kzlQFOaC+Q3zJzjHAjO4S6rYU0isMOq4zT6nPQedVUs=; b=Sj9o+NKRQNxP6BT3mOO7xKRXqvURDpwtMPEObbhAUKHB0G5TZsFqvLRzpivf3siO8p q4OGCKO9jqyWEq60yx+9wOJv1U8USnPkuF8nSaNR7rYGJXE1BMiF2K6k1vLF93EsO458 cXcYd31QyZHvCu7jg66net7rYYIjzyzJo6BAVKN8J5jocQNCu8JIPkJ5c+DQNjNDM0kc RUQy8mFpnJw19n98DDMxnkXK4shtpg4GU5OzSQ6aETc/qeqPMhu7QIfu4FTCtmUi5sjE F2qOjhDq/DKLJh2dPDRAAQbLD92zFc85CLVMowHadGv0yQQPb6fqACaAnq9rPS1HSuMH iydw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695283650; x=1695888450; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kzlQFOaC+Q3zJzjHAjO4S6rYU0isMOq4zT6nPQedVUs=; b=Sa0WjzAGpPRUA4cz5tOUj5RavRljhxUjLUJm0YRTwLAjXh06OD0Tse7JxHlbnAaNqk 2pdoH987CjEVKOpGjnNWML3xcg3d1KVnzyJZDEyxachsU8fGKG8mhymTT1ZsH+EyMFRa SQzbOPC316W4Nwd6oroVVuAjIokU3NfEcUOraAJYMXYn1hWCK6aWnkwceQuEtgaMkJJY B4ZT9Jwf8p2jtoVjBXKVgPcTOD2o5TyzSiKit294q/Byrpw3wRra5OAYXjAG9QADgO/P 84FtYB57c0hkxYPipHIIf4zdBvjsY2JoZDOcVGjnDj8s2aO9gw9mq2FWqE1IdLX33fAs 1GIQ== X-Gm-Message-State: AOJu0YzfqVS9K45MCeH8i6MsqPXpqTyxx7FPuF047FsE/fze9Hg8+APx 58oXgbsV6WVG3pSuEfLsgnqLw++7IdVvWNl2MO0= X-Google-Smtp-Source: AGHT+IFZLzC/Z7NkNUmpXPqr6ukiZmFOtFhuJR3x9TQUbLK/L3UtGCaWpRszIrQRqQwLNGpHq/i9FeFtbtj6mfhnitA= X-Received: by 2002:a2e:924d:0:b0:2bf:aba1:d951 with SMTP id v13-20020a2e924d000000b002bfaba1d951mr4475355ljg.10.1695283649821; Thu, 21 Sep 2023 01:07:29 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Sep 2023 01:07:29 -0700 From: Stefan Kangas In-Reply-To: <83zg1hay6q.fsf@gnu.org> References: <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> MIME-Version: 1.0 Date: Thu, 21 Sep 2023 01:07:29 -0700 Message-ID: Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max To: Eli Zaretskii , Dmitry Gutov , Stefan Monnier Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Stefan & Stefan: any comments or suggestions? FWIW, I've had the below snippet in my .emacs for the last two years, and haven't noticed any adverse effects. I never bothered making any actual benchmarks though: ;; Maybe faster: (setq read-process-output-max (max read-process-output-max (* 64 1024))) I added the above after the discussion here: https://lists.gnu.org/r/emacs-devel/2021-03/msg01461.html From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 09:16:47 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 13:16:47 +0000 Received: from localhost ([127.0.0.1]:33003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjJXy-0004XN-Nt for submit@debbugs.gnu.org; Thu, 21 Sep 2023 09:16:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjJXu-0004X7-4U for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 09:16:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJXd-0000aL-Nq; Thu, 21 Sep 2023 09:16:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BltP3jySIVDwuXLIIfafYqDJQOceK1PSJ1ImbPUVUHQ=; b=Ig5AmKuCesIA So6GnFKcU9Y0/XpYeRgrIP54tPXRl0X5l6WWN9/py/4i1N+Z06mgwhoZppAT8G92Rb/5WySL0pdoq t654H5JWezPmbhHuL1HP2/9JclMJkEvkZa714ZGxlMZoCgpLWOp6tGiWcWT7LQP6Mgx4SPdzbkMZ0 p5hE6ITr8SLcxFYD9WDo9NnpajX8hAu81gSioyv3p8p0jHALkUtbTXPHKkxgc4+/E0B8zgzr5arbo QCF33M6J2p5XdzTEJCVtH8Pv+Ysf0Od8xyD0Db4e4QZzRgdxReEzYL5w3TBvVrtN8gksaraOq7WF8 LFIcYDOiGUCFIIZuDbgj0Q==; Date: Thu, 21 Sep 2023 16:16:31 +0300 Message-Id: <834jjnacpc.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <58e9135f-915d-beb9-518a-e814ec2a0c5b@gutov.dev> (message from Dmitry Gutov on Thu, 21 Sep 2023 15:20:57 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <58e9135f-915d-beb9-518a-e814ec2a0c5b@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 15:20:57 +0300 > Cc: Eli Zaretskii , Stefan Kangas , > 66020@debbugs.gnu.org > From: Dmitry Gutov > > On 21/09/2023 05:36, Stefan Monnier wrote: > >> make_process), although I had to use a value produced by make_uninit_string: > >> apparently simply storing a char* field inside a managed structure creates > >> problems for the GC and early segfaults. Anyway, the result was slightly > > That should depend on*where* you put that field. Basically, it has to > > come after: > > > > /* The thread a process is linked to, or nil for any thread. */ > > Lisp_Object thread; > > /* After this point, there are no Lisp_Objects. */ > > > > since all the words up to that point will be traced by the GC (and > > assumed to be Lisp_Object fields). > > Ah, thanks. That calls for another try. > > ...still no improvement, though no statistically significant slowdown > either this time. Why did you expect a significant improvement? Allocating and freeing the same-size buffer in quick succession has got to be optimally handled by modern malloc implementations, so I wouldn't be surprised by what you discover. There should be no OS calls, just reuse of a buffer that was just recently free'd. The overhead exists, but is probably very small, so it is lost in the noise. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 09:17:45 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 13:17:45 +0000 Received: from localhost ([127.0.0.1]:33008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjJYv-0004Z1-7B for submit@debbugs.gnu.org; Thu, 21 Sep 2023 09:17:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjJYt-0004Yp-RP for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 09:17:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJYc-00011s-Qy; Thu, 21 Sep 2023 09:17:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rUvAryZyNSyJmK+FWZ2CWBuYlTLCp+FEOigX0z1E/VQ=; b=Jv5t0szL2Lac xnoPIfJDOIRF7mXDRMxbhIG9k+EUoCwZthSuTfCOgUnRJWm1mk2ydLidzAciwKm1ubQbx06rqVZiC 4GRNEmev9OPewnzalG/zsaiSjU7lBvZlIXFrceqMOJSRiukTEDNEx/a+pr8zvW6hrQthgfXnJc9xb ajES7FPBOVHOyGTeJ/NAD0T0+fPAgqf2F5VTyXVVzItCjLWIGIN2BL8dFuj40uHyfYkzTufma46Yy QB4WN6BgcxGtPr32SfisRDKmq7nEWVOzv9vrL6o8Q/wuJ4QCVEP9ektxVZkTCPKdeaeuWNIW8hKpP Rc9AWfvofI5OVgzPlX1T1g==; Date: Thu, 21 Sep 2023 16:17:31 +0300 Message-Id: <8334z7acno.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 21 Sep 2023 15:27:41 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 15:27:41 +0300 > Cc: 66020@debbugs.gnu.org > From: Dmitry Gutov > > > https://lists.gnu.org/r/emacs-devel/2021-03/msg01461.html > > The archive seems down (so I can't read this), but if you found a > tangible improvement from the above setting, you might also want to try > out the patch at the top of this bug report. It is back up now. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 10:37:49 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 14:37:49 +0000 Received: from localhost ([127.0.0.1]:34598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjKoO-00075t-MQ for submit@debbugs.gnu.org; Thu, 21 Sep 2023 10:37:49 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:34597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjKoJ-00075a-4H for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 10:37:47 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9409D5C0180; Thu, 21 Sep 2023 10:37:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 21 Sep 2023 10:37:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695307047; x=1695393447; bh=SGAA9obZLcqxFDzFTRshOfwhArV4juGnY0h ntVoMqyE=; b=4M8xYXQOmo9fzfqxBvzoiVOx0CQIO49AnGfaInGAb0sZlHypFOK R62WYTSvZDr5X3j+kzLkBpfluEEafhZ4BHi9CnffbzOTpnJB+8f2rI8gRMXf6JMt tIrtl66VBHYGnATBCquLqMaRwNc4yPekdarFERI0ml9C7/ESyu0bAK5JsMeCeXlF n1c6AGIWjI0h3vjdv6MaeOoioarcUzMwz7t183n4V0Bq9XJTRcMsgmTdJ/1xYy49 +jcKo3JeWYAMKyxOU8ibqMb3BF1CmmnLvNEbCacVmjXtLj51KxePQXX/7CM/SEW0 fSeB2mjuhGApEDuXeEgd8o86KK9U9UEZQXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695307047; x=1695393447; bh=SGAA9obZLcqxFDzFTRshOfwhArV4juGnY0h ntVoMqyE=; b=p6uhDK7uhGL39RuSWIu+j7VRamjra2hM/fm5rHZ0CHTRs9oh7Ab Imq+12H62pjHLzbjoVFSs7DBggUanE2GosRdV0OcqBCtvu2k7vCx8D0t2g1g2tpA goLuyJoY5EodWJS+DV40tRFIPXH9pplk90iYkkigL+yHL7L3kEGvRyLtqLEIhWNi EiuwPc3TOO8iUjghABlY0f5Y2GB3Nl1W43z3PkPKslgfN8tN0hD3ULzOXdUYjAlc 3pDppjAIch3YzD38n7OSitT9GoVUsK2pxGzjzuU9zuTZVdiA0o+Cci3XAKIlEaVd 7O5Fwg1mcLJfxQce67NZ9ETIjtPxagcSjjA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 10:37:25 -0400 (EDT) Message-ID: Date: Thu, 21 Sep 2023 17:37:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii References: <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83led09dlk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 21/09/2023 10:42, Eli Zaretskii wrote: >> Date: Thu, 21 Sep 2023 03:57:43 +0300 >> Cc: 66020@debbugs.gnu.org >> From: Dmitry Gutov >> >> That leaves the question of what new value to use. 409600 is optimal for >> a large-output process but seems too much as default anyway (even if I >> have very little experimental proof for that hesitance: any help with >> that would be very welcome). > > How does the throughput depend on this value? If the dependence curve > plateaus at some lower value, we could use that lower value as a > "good-enough" default. Depends on what we're prepared to call a plateau. Strictly speaking, not really. But we have a "sweet spot": for the process in my original benchmark ('find' with lots of output) it seems to be around 1009600. Here's a table (numbers are different from before because they're results of (benchmark 5 ...) divided by 5, meaning GC is amortized: | 4096 | 0.78 | | 16368 | 0.69 | | 40960 | 0.65 | | 409600 | 0.59 | | 1009600 | 0.56 | | 2009600 | 0.64 | | 4009600 | 0.65 | The process's output length is 27244567 in this case. Still above the largest of the buffers in this example. Notably, only allocating the buffer once at the start of the process (experiment mentioned in the email to Stefan M.) doesn't change the dynamics: buffer lengths above ~1009600 make the performance worse. So there must be some negative factor associated with higher buffers. There is an obvious positive one: the longer the buffer, the longer we don't switch between processes, so that overhead is lower. We could look into improving that part specifically: for example, reading from the process multiple times into 'chars' right away while there is still pending output present (either looping inside read_process_output, or calling it in a loop in wait_reading_process_output, at least until the process' buffered output is exhausted). That could reduce reactivity, however (can we find out how much is already buffered in advance, and only loop until we exhaust that length?) >> I did some more experimenting, though. At a superficial glance, >> allocating the 'chars' buffer at the beginning of read_process_output is >> problematic because we could instead reuse a buffer for the whole >> duration of the process. I tried that (adding a new field to >> Lisp_Process and setting it in make_process), although I had to use a >> value produced by make_uninit_string: apparently simply storing a char* >> field inside a managed structure creates problems for the GC and early >> segfaults. Anyway, the result was slightly _slower_ than the status quo. >> >> So I read what 'alloca' does, and it looks hard to beat. But it's only >> used (as you of course know) when the value is <= MAX_ALLOCA, which is >> currently 16384. Perhaps an optimal default value shouldn't exceed this, >> even if it's hard to create a benchmark that shows a difference. With >> read-process-output-max set to 16384, my original benchmark gets about >> halfway to the optimal number. > > Which I think means we should stop worrying about the overhead of > malloc for this purpose, as it is fast enough, at least on GNU/Linux. Perhaps. If we're not too concerned about memory fragmentation (that's the only explanation I have for the table "session gets older" -- last one -- in a previous email with test-ls-output timings). >> And I think we should make the process "remember" the value at its >> creation either way (something touched on in bug#38561): in bug#55737 we >> added an fcntl call to make the larger values take effect. But this call >> is in create_process: so any subsequent increase to a large value of >> this var won't have effect. > > Why would the variable change after create_process? I'm afraid I > don't understand what issue you are trying to deal with here. Well, what could we lose by saving the value of read-process-output-max in create_process? Currently I suppose one could vary its value while a process is still running, to implement some adaptive behavior or whatnot. But that's already semi-broken because fcntl is called in create_process. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 10:59:50 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 14:59:50 +0000 Received: from localhost ([127.0.0.1]:34632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjL9i-0007hR-33 for submit@debbugs.gnu.org; Thu, 21 Sep 2023 10:59:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjL9f-0007h9-M8 for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 10:59:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjL9O-000337-BG; Thu, 21 Sep 2023 10:59:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rSfwGjfpGCZpMB1Vt2IAruMLKEuwhJ3wI6RL8LVl8jE=; b=UWssMuD/MqfF +VbG34meYO5/H0TxgQZl8Jzo3UPOscdajcoJzfmgcHK0rd2LE1cKRe8EENg8H597+APyqc+6HM+1g WDVvSmMyDWO+wTONO6HpOdfg0Wb686YeS/zAhyS6qe24ApAcJUxARfkSWzgi1uaU75KtFvQHeTp4Q XlrM/JN5pE5F7BJNkRc/p8lno/Puu0aDc6hDv1LnTfzIrf3BDd0KsZfTwxgbY7JrTXB4lSLlJgmGn MAVBNnJNaQkHSIQTh4/DSbe2+8pOH8MNrtpBJnJt+oyJTvmFTk5mIo3UhPKQSGwkxeElwL+pNa1XH UhuPw480/eVbI8u5GgVNYg==; Date: Thu, 21 Sep 2023 17:59:36 +0300 Message-Id: <83msxf8td3.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 21 Sep 2023 17:37:23 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <83bkfs2tw5.fsf@gnu.org> <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 17:37:23 +0300 > Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, 66020@debbugs.gnu.org > From: Dmitry Gutov > > > How does the throughput depend on this value? If the dependence curve > > plateaus at some lower value, we could use that lower value as a > > "good-enough" default. > > Depends on what we're prepared to call a plateau. Strictly speaking, not > really. But we have a "sweet spot": for the process in my original > benchmark ('find' with lots of output) it seems to be around 1009600. > Here's a table (numbers are different from before because they're > results of (benchmark 5 ...) divided by 5, meaning GC is amortized: > > | 4096 | 0.78 | > | 16368 | 0.69 | > | 40960 | 0.65 | > | 409600 | 0.59 | > | 1009600 | 0.56 | > | 2009600 | 0.64 | > | 4009600 | 0.65 | Not enough data points between 40960 and 409600, IMO. 40960 sounds like a good spot for the default value. > >> And I think we should make the process "remember" the value at its > >> creation either way (something touched on in bug#38561): in bug#55737 we > >> added an fcntl call to make the larger values take effect. But this call > >> is in create_process: so any subsequent increase to a large value of > >> this var won't have effect. > > > > Why would the variable change after create_process? I'm afraid I > > don't understand what issue you are trying to deal with here. > > Well, what could we lose by saving the value of read-process-output-max > in create_process? It's already recorded in the size of the pipe, so why would we need to record it once more? > Currently I suppose one could vary its value while a process is > still running, to implement some adaptive behavior or whatnot. But > that's already semi-broken because fcntl is called in > create_process. I see no reason to support such changes during the process run, indeed. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 13:33:53 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 17:33:53 +0000 Received: from localhost ([127.0.0.1]:34764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNYm-0003bR-GW for submit@debbugs.gnu.org; Thu, 21 Sep 2023 13:33:52 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:57821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNYk-0003b9-5n for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 13:33:51 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 686125C0ABC; Thu, 21 Sep 2023 13:33:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 21 Sep 2023 13:33:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1695317613; x=1695404013; bh=DG nJ6hz40L8fhUpX2K1tJ1iJM4MSo4bd/bEkm/5yTfo=; b=2qsGKFrNuJPueZoAL/ lqu0GOu3188LeapqqwbtJJIjBm2F7CdLPe47B4wT3sC5tEpvv212nfZAPm+tbtwG RAVx6d6IDFWlMSyCSUYxQU398tBB972eoWXl/h5fkBh7tS3Rou4C34F6KGPRX9Up ZWgSuJ7juuY7+PnyUPoaxoJZW+G+WbUQiR94qYusfFV1EPHo8p6TRh0AqB2vvpQT 5YIwajPiJ3fqaVUDkQMmTyoEHXqOq6ZPCVPGxBBtBfTK8SrosnVrYuNRyq7fRA8v IsGUJKZ3YsNSb7nJJvigm5gGWw4sZOHzDFRRrHh2QJt0JbqNdaN3saKoRPbwLlOC y7CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1695317613; x=1695404013; bh=DGnJ6hz40L8fh UpX2K1tJ1iJM4MSo4bd/bEkm/5yTfo=; b=PiCbwzr7t8o9CLwtl6PrpGPnkuXOx Xk5TorRCQRcJXbr3LgVD83ib24Z7d8hS+J3sMe7NOCVwGRLdm/VowEGLEItBq4J4 0ySij+rfUcr0ZlWm7oLvo9TTOU5r6E6SdOfrhaKVSVQYym/P73HexAo4qqwIAhxZ 5Z08AtnsH8gedWkzi2t1FqBIfB7cu/v99do8Dg02Yi3pO4GmF0wJT/2CJY+wMEln MM14IOQrDQaBmB3Zmn2QF83fBjRpMtbzepBhFIptpXK7pSRjwHlFxkWw0jMQq8Xz wbqHKl+IX12MFdmqzzK84QUK06GMNAczll3uBD/pexj+KOYH9G3ZjrjBA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtkfffgggfuffhvfevfhgjsehmtderredtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepieehgeektefggfehhfegieevuedugedvueetfffhtedtleelheekffelvddu tdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 13:33:31 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------X2wXDJQTrLHnoyaJptdb0Mbn" Message-ID: <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> Date: Thu, 21 Sep 2023 20:33:29 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US From: Dmitry Gutov To: Eli Zaretskii References: <18a0b4d8-32bd-3ecd-8db4-32608a1ebba7@gutov.dev> <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> In-Reply-To: X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) This is a multi-part message in MIME format. --------------X2wXDJQTrLHnoyaJptdb0Mbn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 21/09/2023 17:37, Dmitry Gutov wrote: > We could look into improving that part specifically: for example, > reading from the process multiple times into 'chars' right away while > there is still pending output present (either looping inside > read_process_output, or calling it in a loop in > wait_reading_process_output, at least until the process' buffered output > is exhausted). That could reduce reactivity, however (can we find out > how much is already buffered in advance, and only loop until we exhaust > that length?) Hmm, the naive patch below offers some improvement for the value 4096, but still not comparable to raising the buffer size: 0.76 -> 0.72. diff --git a/src/process.c b/src/process.c index 2376d0f288d..a550e223f78 100644 --- a/src/process.c +++ b/src/process.c @@ -5893,7 +5893,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, && ((fd_callback_info[channel].flags & (KEYBOARD_FD | PROCESS_FD)) == PROCESS_FD)) { - int nread; + int nread = 0, nnread; /* If waiting for this channel, arrange to return as soon as no more input to be processed. No more @@ -5912,7 +5912,13 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, /* Read data from the process, starting with our buffered-ahead character if we have one. */ - nread = read_process_output (proc, channel); + do + { + nnread = read_process_output (proc, channel); + nread += nnread; + } + while (nnread >= 4096); + if ((!wait_proc || wait_proc == XPROCESS (proc)) && got_some_output < nread) got_some_output = nread; And "unlocking" the pipe size on the external process takes the performance further up a notch (by default it's much larger): 0.72 -> 0.65. diff --git a/src/process.c b/src/process.c index 2376d0f288d..85fc1b4d0c8 100644 --- a/src/process.c +++ b/src/process.c @@ -2206,10 +2206,10 @@ create_process (Lisp_Object process, char **new_argv, Lisp_Object current_dir) inchannel = p->open_fd[READ_FROM_SUBPROCESS]; forkout = p->open_fd[SUBPROCESS_STDOUT]; -#if (defined (GNU_LINUX) || defined __ANDROID__) \ - && defined (F_SETPIPE_SZ) - fcntl (inchannel, F_SETPIPE_SZ, read_process_output_max); -#endif /* (GNU_LINUX || __ANDROID__) && F_SETPIPE_SZ */ +/* #if (defined (GNU_LINUX) || defined __ANDROID__) \ */ +/* && defined (F_SETPIPE_SZ) */ +/* fcntl (inchannel, F_SETPIPE_SZ, read_process_output_max); */ +/* #endif /\* (GNU_LINUX || __ANDROID__) && F_SETPIPE_SZ *\/ */ } if (!NILP (p->stderrproc)) Apparently the patch from bug#55737 also made things a little worse by default, by limiting concurrency (the external process has to wait while the pipe is blocked, and by default Linux's pipe is larger). Just commenting it out makes performance a little better as well, though not as much as the two patches together. Note that both changes above are just PoC (e.g. the hardcoded 4096, and probably other details like carryover). I've tried to make a more nuanced loop inside read_process_output instead (as replacement for the first patch above), and so far it performs worse that the baseline. If anyone can see when I'm doing wrong (see attachment), comments are very welcome. --------------X2wXDJQTrLHnoyaJptdb0Mbn Content-Type: text/x-patch; charset=UTF-8; name="read_process_output_nn_inside.diff" Content-Disposition: attachment; filename="read_process_output_nn_inside.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9wcm9jZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IDIzNzZk MGYyODhkLi45MWE1YzA0NGE4YyAxMDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9z cmMvcHJvY2Vzcy5jCkBAIC02MTI4LDExICs2MTMzLDExIEBAIHJlYWRfYW5kX2Rpc3Bvc2Vf b2ZfcHJvY2Vzc19vdXRwdXQgKHN0cnVjdCBMaXNwX1Byb2Nlc3MgKnAsIGNoYXIgKmNoYXJz LAogc3RhdGljIGludAogcmVhZF9wcm9jZXNzX291dHB1dCAoTGlzcF9PYmplY3QgcHJvYywg aW50IGNoYW5uZWwpCiB7Ci0gIHNzaXplX3QgbmJ5dGVzOworICBzc2l6ZV90IG5ieXRlcywg bm5ieXRlcyA9IDA7CiAgIHN0cnVjdCBMaXNwX1Byb2Nlc3MgKnAgPSBYUFJPQ0VTUyAocHJv Yyk7CiAgIGVhc3NlcnQgKDAgPD0gY2hhbm5lbCAmJiBjaGFubmVsIDwgRkRfU0VUU0laRSk7 CiAgIHN0cnVjdCBjb2Rpbmdfc3lzdGVtICpjb2RpbmcgPSBwcm9jX2RlY29kZV9jb2Rpbmdf c3lzdGVtW2NoYW5uZWxdOwotICBpbnQgY2FycnlvdmVyID0gcC0+ZGVjb2RpbmdfY2Fycnlv dmVyOworICBpbnQgY2FycnlvdmVyOwogICBwdHJkaWZmX3QgcmVhZG1heCA9IGNsaXBfdG9f Ym91bmRzICgxLCByZWFkX3Byb2Nlc3Nfb3V0cHV0X21heCwgUFRSRElGRl9NQVgpOwogICBz cGVjcGRsX3JlZiBjb3VudCA9IFNQRUNQRExfSU5ERVggKCk7CiAgIExpc3BfT2JqZWN0IG9k ZWFjdGl2YXRlOwpAQCAtNjE0MSw2ICs2MTQ2LDkgQEAgcmVhZF9wcm9jZXNzX291dHB1dCAo TGlzcF9PYmplY3QgcHJvYywgaW50IGNoYW5uZWwpCiAgIFVTRV9TQUZFX0FMTE9DQTsKICAg Y2hhcnMgPSBTQUZFX0FMTE9DQSAoc2l6ZW9mIGNvZGluZy0+Y2FycnlvdmVyICsgcmVhZG1h eCk7CiAKK2RveworICBjYXJyeW92ZXIgPSBwLT5kZWNvZGluZ19jYXJyeW92ZXI7CisKICAg aWYgKGNhcnJ5b3ZlcikKICAgICAvKiBTZWUgdGhlIGNvbW1lbnQgYWJvdmUuICAqLwogICAg IG1lbWNweSAoY2hhcnMsIFNEQVRBIChwLT5kZWNvZGluZ19idWYpLCBjYXJyeW92ZXIpOwpA QCAtNjIyMiwzICs2MjM2LDMgQEAgcmVhZF9wcm9jZXNzX291dHB1dCAoTGlzcF9PYmplY3Qg cHJvYywgaW50IGNoYW5uZWwpCiAgIC8qIE5vdyBzZXQgTkJZVEVTIGhvdyBtYW55IGJ5dGVz IHdlIG11c3QgZGVjb2RlLiAgKi8KICAgbmJ5dGVzICs9IGNhcnJ5b3ZlcjsKIApAQCAtNjIz Myw1ICs2MjQ1LDggQEAKICAgLyogSGFuZGxpbmcgdGhlIHByb2Nlc3Mgb3V0cHV0IHNob3Vs ZCBub3QgZGVhY3RpdmF0ZSB0aGUgbWFyay4gICovCiAgIFZkZWFjdGl2YXRlX21hcmsgPSBv ZGVhY3RpdmF0ZTsKIAorICBubmJ5dGVzICs9IG5ieXRlczsKKyB9IHdoaWxlIChuYnl0ZXMg Pj0gcmVhZG1heCk7CisKICAgU0FGRV9GUkVFX1VOQklORF9UTyAoY291bnQsIFFuaWwpOwot ICByZXR1cm4gbmJ5dGVzOworICByZXR1cm4gbm5ieXRlczsKfQoK --------------X2wXDJQTrLHnoyaJptdb0Mbn-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 13:40:57 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 17:40:57 +0000 Received: from localhost ([127.0.0.1]:34771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNfc-0003mI-I3 for submit@debbugs.gnu.org; Thu, 21 Sep 2023 13:40:57 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:48957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNfZ-0003m4-Nb for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 13:40:54 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7295B5C0083; Thu, 21 Sep 2023 13:40:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 21 Sep 2023 13:40:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695318038; x=1695404438; bh=BCbwPkLFW24nXas7752ku61z+VT8UPOlKLv ohBTMUgs=; b=IaFWWAFTN+AkYAvWylBs0GyE3LtOEQQz6XjJoEN0lQiJz4JoQEU qn21u96oODeSZmmxy+a9/vrfCXAxdEi4O4GAlhz6hOcyv8m9AGqYm4xueQ9hWrnm BbZwYt6YcUj0zhc4KWkA2nANb1ETLAY/mfaKjDfyST45gB4xNlmLIAvRp+KFJqzB 9juq2l6ogMLl05Pn9Zz4MPMbzU8saXZv8GGidk3/NCbTattpDOlcL0jjlBQ7krCx JDWElGwh9gdCcC1+vWKbqmjKlJ6P2krMPZS4LVxoon2NdNtrV3JTH4ImipNQqmin Vh/KE6auLA0UZdp3skmbsoqI8ZryHNU0mnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695318038; x=1695404438; bh=BCbwPkLFW24nXas7752ku61z+VT8UPOlKLv ohBTMUgs=; b=jSSWvIXkkxGhHM9LUFcKYsglhUaK9tTnzxEadwqbcqAKp7ZGz2o v2pDaKWNPgZVXAuksS089+oUJqZYHG0BUKIsRa5kCiI3Ks3Qe+NeErIQaal5Kexm PHDSuSPG051opUgvv8uSkrmj6eJsUiC1GWBSNQ2q2nVbrnDL5+YOFyAED6fM56hd +2KWYdyPpTa3MLPrqR+dA8lK98dFFqeY6AaldJL8DwFEHTImhrNYdnHVtcYvs3Rf 2YnIzF3QKcsvhXWT1rJRG76I08A5GNbyLxWfwViRvjjBRij24HZ6+lyGgYiM1dEX ZHGQsZ8pQvUTDAMIIV1p/y+7r588UC6OlEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 13:40:36 -0400 (EDT) Message-ID: <4dd10ea8-6124-a50d-2bc2-1fced50e34cc@gutov.dev> Date: Thu, 21 Sep 2023 20:40:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii References: <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <83msxf8td3.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83msxf8td3.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 21/09/2023 17:59, Eli Zaretskii wrote: >> Date: Thu, 21 Sep 2023 17:37:23 +0300 >> Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, 66020@debbugs.gnu.org >> From: Dmitry Gutov >> >>> How does the throughput depend on this value? If the dependence curve >>> plateaus at some lower value, we could use that lower value as a >>> "good-enough" default. >> >> Depends on what we're prepared to call a plateau. Strictly speaking, not >> really. But we have a "sweet spot": for the process in my original >> benchmark ('find' with lots of output) it seems to be around 1009600. >> Here's a table (numbers are different from before because they're >> results of (benchmark 5 ...) divided by 5, meaning GC is amortized: >> >> | 4096 | 0.78 | >> | 16368 | 0.69 | >> | 40960 | 0.65 | >> | 409600 | 0.59 | >> | 1009600 | 0.56 | >> | 2009600 | 0.64 | >> | 4009600 | 0.65 | > > Not enough data points between 40960 and 409600, IMO. 40960 sounds > like a good spot for the default value. Or 32K, from the thread linked to previously (datagram size). And ifwe were to raise MAX_ALLOCA by 2x, we could still use 'alloca'. Neither would be optimal for my test scenario, though still an improvement. But see my other email with experimental patches, those bear improvement with the default 4096. >>>> And I think we should make the process "remember" the value at its >>>> creation either way (something touched on in bug#38561): in bug#55737 we >>>> added an fcntl call to make the larger values take effect. But this call >>>> is in create_process: so any subsequent increase to a large value of >>>> this var won't have effect. >>> >>> Why would the variable change after create_process? I'm afraid I >>> don't understand what issue you are trying to deal with here. >> >> Well, what could we lose by saving the value of read-process-output-max >> in create_process? > > It's already recorded in the size of the pipe, so why would we need to > record it once more? 'read_process_output' looks it up once more, to set the value of 'readmax' and allocate char*chars. Can we get the "recorded" value back from the pipe somehow? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 13:54:53 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 17:54:53 +0000 Received: from localhost ([127.0.0.1]:34783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNt6-0004Cu-NY for submit@debbugs.gnu.org; Thu, 21 Sep 2023 13:54:53 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:45323) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjNt2-0004Cc-BL for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 13:54:51 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1469D5C01C8; Thu, 21 Sep 2023 13:54:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 21 Sep 2023 13:54:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695318873; x=1695405273; bh=q1B7TLI6SOwqcxTBfNXZje7JR5MuPKu9Rsq YHLY9Bow=; b=Gjyf+JcEN2jtTsyOQwAJd984QkCTXjQYvs/g80wrB4fSio67C2C XI9p2fU7c+4NAoX9NVoyjmKfjglAyt2DqiTpsWrPjzrPjX4iu+iSEaeQEu7IHcbf yKJZEcgmJ80g8TWYIWKXyb9ydKl/GeeQSk382ZgjgleQZj3XHBJiXcZL8Fogz1yJ mCBLiyy36ud5GYQlxgVnRR+WMXCHFq6eHjeT42dup7K5SYyP7fxEp+yvDyaiMgTu Sfb56hk4nzJO4T1OWR/8d6H+vRrXyCzYzhvcZDlLrL4+rJ7VejLEfu8BpLtynSzN NGCWxFCTqcEyZXd/KI+J6CrwUdSBFYh6CIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695318873; x=1695405273; bh=q1B7TLI6SOwqcxTBfNXZje7JR5MuPKu9Rsq YHLY9Bow=; b=AfMxk7UTLymPFy1xqGzx6Lsr7R1+JG1NeyDcKqyepTLpVMwxoqZ N81RVu0r99x0OSmR3JS8wWk3xJZCe3QY0J4PALnvSPF+b7iexVnVxyppO3ENQHMK P6+oHEW0GFX/Vr0MtlwBXzcI1Saj6mJvlVcKdOmvX+rz+YcC0GhvePG8tmqFRTZf nlwvJVzHdEvABTlG8xByErWGWmeUDQGqHHFSg2LTmwrNooVzzP/Q6uwtZc7o9YLD RcaXd505Nm8BGGZ8zWlqNtV0gDyLk3FYSGmewMsNcCsLRgCqzdUbu2R3BN2Gjl55 PNM+RcgAwK+OhjFI26wqyi9+DFN57Nnsstw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedv vdejleenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 13:54:31 -0400 (EDT) Message-ID: <83f3d122-f11a-d0b7-60c6-9b0c4812cd4d@gutov.dev> Date: Thu, 21 Sep 2023 20:54:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <58e9135f-915d-beb9-518a-e814ec2a0c5b@gutov.dev> <834jjnacpc.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <834jjnacpc.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 21/09/2023 16:16, Eli Zaretskii wrote: >> Date: Thu, 21 Sep 2023 15:20:57 +0300 >> Cc: Eli Zaretskii, Stefan Kangas, >> 66020@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 21/09/2023 05:36, Stefan Monnier wrote: >>>> make_process), although I had to use a value produced by make_uninit_string: >>>> apparently simply storing a char* field inside a managed structure creates >>>> problems for the GC and early segfaults. Anyway, the result was slightly >>> That should depend on*where* you put that field. Basically, it has to >>> come after: >>> >>> /* The thread a process is linked to, or nil for any thread. */ >>> Lisp_Object thread; >>> /* After this point, there are no Lisp_Objects. */ >>> >>> since all the words up to that point will be traced by the GC (and >>> assumed to be Lisp_Object fields). >> Ah, thanks. That calls for another try. >> >> ...still no improvement, though no statistically significant slowdown >> either this time. > Why did you expect a significant improvement? No need to be surprised, I'm still growing intuition for what is fast and what is slow at this level of abstraction. > Allocating and freeing > the same-size buffer in quick succession has got to be optimally > handled by modern malloc implementations, so I wouldn't be surprised > by what you discover. There should be no OS calls, just reuse of a > buffer that was just recently free'd. The overhead exists, but is > probably very small, so it is lost in the noise. There are context switches after 'read_process_output' exits (control is returned to Emacs's event loop, the external process runs again, we wait on it with 'select'), it might not be there later, especially outside of the lab situation where we benchmark just single external process. So I don't know. I'm not majorly concerned, of course, and wouldn't be at all, if not for the previously recorded minor degragation with larger buffers in the longer-running session (last table in https://debbugs.gnu.org/66020#10). From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 14:39:43 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 18:39:44 +0000 Received: from localhost ([127.0.0.1]:34800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOaV-0005OS-IR for submit@debbugs.gnu.org; Thu, 21 Sep 2023 14:39:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOaU-0005OD-6s for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 14:39:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjOaE-0003LA-JH; Thu, 21 Sep 2023 14:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NfRc+JfVW2mG341m4CoblLYVZAHK2mHyk/gMnAiKaEg=; b=B1nfqNjJMx0G kUZGxd44jotVfq6BfOrqvJiXzkPge722IpcMU+/ZbYy9RuxyvsIYsm6HokdntaYZi46OepgMJA8bE J0ZzacbMoqGfuPblS1Bq83xAqgy0+CjyWjnjGglxmPUN8a2AA4WQkpqMy5nokerm5mZ+YylCiiCdW 920760cCkIWWEJe8vmEgR7USSxf3SvFEOMVIeoLCAyMwz8FY+uMbE+n11oHy+V0enS61fzvpRfigH MdmUOayCHhM01phwEUyvakKPhYV1oy6/T45DWv9rEDyXVsWzOv6vH+YjeW5FjMAMcDBm7QF1EoGKW zoT0Mw2QeI80TCfisvLSNA==; Date: Thu, 21 Sep 2023 21:39:34 +0300 Message-Id: <83h6nn8j6h.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <4dd10ea8-6124-a50d-2bc2-1fced50e34cc@gutov.dev> (message from Dmitry Gutov on Thu, 21 Sep 2023 20:40:35 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <83msxf8td3.fsf@gnu.org> <4dd10ea8-6124-a50d-2bc2-1fced50e34cc@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 20:40:35 +0300 > Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, 66020@debbugs.gnu.org > From: Dmitry Gutov > > Can we get the "recorded" value back from the pipe somehow? There's F_GETPIPE_SZ command to fcntl, so I think we can. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 14:42:27 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 18:42:27 +0000 Received: from localhost ([127.0.0.1]:34805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOd9-0005So-4b for submit@debbugs.gnu.org; Thu, 21 Sep 2023 14:42:27 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:53245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOd4-0005SY-4i for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 14:42:25 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8833432007D7; Thu, 21 Sep 2023 14:42:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 21 Sep 2023 14:42:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695321725; x=1695408125; bh=P+rDt2VrIj2asnmjEEYCHgmU5hOP63BUQaS vRwhZi9w=; b=tTxbr4BRqLdi2UmmOacanxvkEe/+D/y0zkhODYxoH6hamw1nN26 3VGnImM715DIM70BGhZ3nYzFCcDUE6pTTsqzC6t4WChNLMpOX2wo/a/4J05Np6V2 8bOzSlzS6Bcal11xG1s7frihbzzol0Oiy905hmcL0sWUP8agipJXdkumPlQGHjoi Bfu/6UVH4rJpDQ0K1iZE1iQqaPzcfgGpMBfctYzUpmU7Yqhv7CYXYCp04HgAaXFR SpB/dfpBoJeJrCT0pTKLPMKrvIS753fM0MVy9wxVD6PBzyygCYhUkt0htaYsJxIk MI3SZ2dmwcV4/h+krAoWQhcE4S8Egu95WGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695321725; x=1695408125; bh=P+rDt2VrIj2asnmjEEYCHgmU5hOP63BUQaS vRwhZi9w=; b=dBxDiJci4phOQmm8uiTtBF9fNjUc2VKv9e0+hk230ebXHZGaJca lzGId5u4xbo+zWEcbAp7/dfn8F5zWNIYU1Uo01yUynTH7+vr2XV4epOR7YMVFJCw PyRgw1zB9PIO8d7ZZE6Wr7499GmjQGSqUg9xFBF0j94uRvD3zCExDaG3NQ62rrIw eRNKFJZirToeJouN0KDLiuLBseBDSEHbSnijkwYofZXq52jS5bZqnX2lNisuq7w6 Vk9NFhTRn7rqLFqNnjI0j8iEC4NNeo3rhMCOn3StfEJoRRxSJxdv9cEPui3LEDdt NYuVqbVesqTSzp2g3iIoZ584nLilcv22K8w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 14:42:03 -0400 (EDT) Message-ID: Date: Thu, 21 Sep 2023 21:42:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US To: Eli Zaretskii References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <83msxf8td3.fsf@gnu.org> <4dd10ea8-6124-a50d-2bc2-1fced50e34cc@gutov.dev> <83h6nn8j6h.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83h6nn8j6h.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 21/09/2023 21:39, Eli Zaretskii wrote: >> Date: Thu, 21 Sep 2023 20:40:35 +0300 >> Cc:stefankangas@gmail.com,monnier@iro.umontreal.ca,66020@debbugs.gnu.org >> From: Dmitry Gutov >> >> Can we get the "recorded" value back from the pipe somehow? > There's F_GETPIPE_SZ command to fcntl, so I think we can. I'll rephrase: is this a good idea (doing a +1 syscall every time we read a chunk, I'm not sure of its performance anyway), or should we add a new field to Lisp_Process after all? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 21 14:49:11 2023 Received: (at 66020) by debbugs.gnu.org; 21 Sep 2023 18:49:11 +0000 Received: from localhost ([127.0.0.1]:34811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOjf-0005jO-1k for submit@debbugs.gnu.org; Thu, 21 Sep 2023 14:49:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qjOjc-0005j9-BA for 66020@debbugs.gnu.org; Thu, 21 Sep 2023 14:49:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjOjM-0005Ex-Gg; Thu, 21 Sep 2023 14:48:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=v4jg5SRZst/tjDO73eEGCFg06m838ZphuBEr9fYBzUY=; b=e5TGVBGYTnzW ws99cAriCyxMx8+W9BT58XfTgfciwGnYmu/rCcAqDMixNQmEwzF9v4YnXk6vEQ5avKElQywoy29Oq SouiqrWGS7ZBXyW4myY1GGsrrQGcIc4Y+yQjslz+yaTWaLZhwTf6dB3XX+WV7oME0rNq7YLuY747q JCua/eDn68mlYk20obiHpn6Y7W/4BCFBWsnv4iD8Af7DFrrk8rMAtbNjfAokIGkBV8gIK04+N53SM auSSMCiYh3LpHMqkGAT7lKVYU1SSqAM+/0avbbUXdr+FZvrxaizrK3c/ODmnL4y74oiJk5UdMPNCv VfFD5kot9XBulGM5mIe1Mg==; Date: Thu, 21 Sep 2023 21:49:00 +0300 Message-Id: <83edir8iqr.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Thu, 21 Sep 2023 21:42:01 +0300) Subject: Re: bug#66020 (bug#64735 spin-off): regarding the default for read-process-output-max References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <83msxf8td3.fsf@gnu.org> <4dd10ea8-6124-a50d-2bc2-1fced50e34cc@gutov.dev> <83h6nn8j6h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 21 Sep 2023 21:42:01 +0300 > Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, 66020@debbugs.gnu.org > From: Dmitry Gutov > > On 21/09/2023 21:39, Eli Zaretskii wrote: > >> Date: Thu, 21 Sep 2023 20:40:35 +0300 > >> Cc:stefankangas@gmail.com,monnier@iro.umontreal.ca,66020@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >> Can we get the "recorded" value back from the pipe somehow? > > There's F_GETPIPE_SZ command to fcntl, so I think we can. > > I'll rephrase: is this a good idea (doing a +1 syscall every time we > read a chunk, I'm not sure of its performance anyway), or should we add > a new field to Lisp_Process after all? If you indeed need the size, then do add it to the process object. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 23 17:51:54 2023 Received: (at 66020) by debbugs.gnu.org; 23 Sep 2023 21:51:54 +0000 Received: from localhost ([127.0.0.1]:40708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkAXZ-0006jA-SI for submit@debbugs.gnu.org; Sat, 23 Sep 2023 17:51:54 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:60373) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkAXW-0006iv-KN for 66020@debbugs.gnu.org; Sat, 23 Sep 2023 17:51:52 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1BBBF3200708; Sat, 23 Sep 2023 17:51:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 23 Sep 2023 17:51:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695505892; x=1695592292; bh=lU2PwP/nCbNrGF9LADRreHQ6651kwnKlFlG HmvnQAKU=; b=F0MM96mM5+hglEDZml84m5bK7mbtivfmA5Cv8RWFMp8pvj4qlUL IK1KVbVU3I3G0bqKcL9W4jG/sH3av+4/3prVLu0ceRJTl/BZVHVeX2jPlCg9ROVB EWuKAz8MGfak+AIhtmF9htMSdqZnu+Mdxpf2YAhUajUeHP00/z4/Sb/rAJ5Lrsa7 xrzoF40fTurqAWR/L8tJ4kbo1D0ip0uO0+wU7xw0CFmvexLbbqg9FlE35MmBRxL6 zeIhLaozN0Ygtd8Z3rkJ4WFscQos0tf6DTJNPyUbz524RZOHIkAfhCDxhESoZ2YW UDMMyAxmyZ+uxM/pH8eGYUJfU/X5XUTPCvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695505892; x=1695592292; bh=lU2PwP/nCbNrGF9LADRreHQ6651kwnKlFlG HmvnQAKU=; b=IP/vPYrNJr777BjwMguIsdSy8cK84ZpbtGWH7YEntN6+q6LAoPA i/bHpzSLmF2ri6IIXDHX1CXIxLbKavkFjrsFyNQX4q6cdI4hWpx+v5af+T4GNmuB 9M47WTWShsdnrf4IgfIJWopvvdMWC/7bBOOg///fF7Tul7DdU2qNvyYq3A8qG3xu 1l3cCV0pqcVQHruo/BzVaqFDzqsw//LDXt1gZvQTGb6+QcwjVhvqkt6Z0523l27K pE4jwWMWnH608B3/KpfkQmaP9lSuYSXSqwRgJtRiTsu12OGmBzt4aYI/VGsCAgMM Gm9S+mrex7XuV6l2B03jmvk4EnVgJS8Takw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeluddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffhvfevfhgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteehheekteegfeeufffgtdetvdduledvjeejffeikeevleevffffiefgueej keelnecuffhomhgrihhnpehsthgrtghkvgigtghhrghnghgvrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhht ohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 23 Sep 2023 17:51:31 -0400 (EDT) Message-ID: Date: Sun, 24 Sep 2023 00:51:28 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max Content-Language: en-US From: Dmitry Gutov To: Eli Zaretskii References: <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> In-Reply-To: <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 Cc: stefankangas@gmail.com, 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) On 21/09/2023 20:33, Dmitry Gutov wrote: > On 21/09/2023 17:37, Dmitry Gutov wrote: >> We could look into improving that part specifically: for example, >> reading from the process multiple times into 'chars' right away while >> there is still pending output present (either looping inside >> read_process_output, or calling it in a loop in >> wait_reading_process_output, at least until the process' buffered >> output is exhausted). That could reduce reactivity, however (can we >> find out how much is already buffered in advance, and only loop until >> we exhaust that length?) > > Hmm, the naive patch below offers some improvement for the value 4096, > but still not comparable to raising the buffer size: 0.76 -> 0.72. > > diff --git a/src/process.c b/src/process.c > index 2376d0f288d..a550e223f78 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5893,7 +5893,7 @@ wait_reading_process_output (intmax_t time_limit, > int nsecs, int read_kbd, >            && ((fd_callback_info[channel].flags & (KEYBOARD_FD | > PROCESS_FD)) >            == PROCESS_FD)) >          { > -          int nread; > +          int nread = 0, nnread; > >            /* If waiting for this channel, arrange to return as >           soon as no more input to be processed.  No more > @@ -5912,7 +5912,13 @@ wait_reading_process_output (intmax_t time_limit, > int nsecs, int read_kbd, >            /* Read data from the process, starting with our >           buffered-ahead character if we have one.  */ > > -          nread = read_process_output (proc, channel); > +          do > +        { > +          nnread = read_process_output (proc, channel); > +          nread += nnread; > +        } > +          while (nnread >= 4096); > + >            if ((!wait_proc || wait_proc == XPROCESS (proc)) >            && got_some_output < nread) >          got_some_output = nread; > > > And "unlocking" the pipe size on the external process takes the > performance further up a notch (by default it's much larger): 0.72 -> 0.65. > > diff --git a/src/process.c b/src/process.c > index 2376d0f288d..85fc1b4d0c8 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -2206,10 +2206,10 @@ create_process (Lisp_Object process, char > **new_argv, Lisp_Object current_dir) >        inchannel = p->open_fd[READ_FROM_SUBPROCESS]; >        forkout = p->open_fd[SUBPROCESS_STDOUT]; > > -#if (defined (GNU_LINUX) || defined __ANDROID__)    \ > -  && defined (F_SETPIPE_SZ) > -      fcntl (inchannel, F_SETPIPE_SZ, read_process_output_max); > -#endif /* (GNU_LINUX || __ANDROID__) && F_SETPIPE_SZ */ > +/* #if (defined (GNU_LINUX) || defined __ANDROID__)    \ */ > +/*   && defined (F_SETPIPE_SZ) */ > +/*       fcntl (inchannel, F_SETPIPE_SZ, read_process_output_max); */ > +/* #endif /\* (GNU_LINUX || __ANDROID__) && F_SETPIPE_SZ *\/ */ >      } > >    if (!NILP (p->stderrproc)) > > Apparently the patch from bug#55737 also made things a little worse by > default, by limiting concurrency (the external process has to wait while > the pipe is blocked, and by default Linux's pipe is larger). Just > commenting it out makes performance a little better as well, though not > as much as the two patches together. > > Note that both changes above are just PoC (e.g. the hardcoded 4096, and > probably other details like carryover). > > I've tried to make a more nuanced loop inside read_process_output > instead (as replacement for the first patch above), and so far it > performs worse that the baseline. If anyone can see when I'm doing wrong > (see attachment), comments are very welcome. This seems to have been a dead end: while looping does indeed make things faster, it doesn't really fit the approach of the 'adaptive_read_buffering' part that's implemented in read_process_output. And if the external process is crazy fast (while we, e.g. when using a Lisp filter, are not so fast), the result could be much reduced interactivity, with this one process keeping us stuck in the loop. But it seems I've found an answer to one previous question: "can we find out how much is already buffered in advance?" The patch below asks that from the OS (how portable is this? not sure) and allocates a larger buffer when more output has been buffered. If we keep OS's default value of pipe buffer size (64K on Linux and 16K-ish on macOS, according to https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer), that means auto-scaling the buffer on Emacs's side depending on how much the process outputs. The effect on performance is similar to the previous (looping) patch (0.70 -> 0.65), and is comparable to bumping read-process-output-max to 65536. So if we do decide to bump the default, I suppose the below should not be necessary. And I don't know whether we should be concerned about fragmentation: this way buffers do get allocates in different sizes (almost always multiples of 4096, but with rare exceptions among larger values). diff --git a/src/process.c b/src/process.c index 2376d0f288d..13cf6d6c50d 100644 --- a/src/process.c +++ b/src/process.c @@ -6137,7 +6145,18 @@ specpdl_ref count = SPECPDL_INDEX (); Lisp_Object odeactivate; char *chars; +#ifdef USABLE_FIONREAD +#ifdef DATAGRAM_SOCKETS + if (!DATAGRAM_CHAN_P (channel)) +#endif + { + int available_read; + ioctl (p->infd, FIONREAD, &available_read); + readmax = MAX (readmax, available_read); + } +#endif + USE_SAFE_ALLOCA; chars = SAFE_ALLOCA (sizeof coding->carryover + readmax); What do people think? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 23 18:46:13 2023 Received: (at 66020) by debbugs.gnu.org; 23 Sep 2023 22:46:14 +0000 Received: from localhost ([127.0.0.1]:40749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkBO8-0008MT-Ms for submit@debbugs.gnu.org; Sat, 23 Sep 2023 18:46:13 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:46099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkBO3-0008Ls-5h for 66020@debbugs.gnu.org; Sat, 23 Sep 2023 18:46:11 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8E1DC320093E; Sat, 23 Sep 2023 18:45:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 23 Sep 2023 18:45:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1695509149; x=1695595549; bh=SK ukJsMAtn0ZO4R01C6lpu2DbBMqwdwX7I/0rIOpOUA=; b=AxUJA6rjNaFQi7ykHm 2pKV6980UYrhMNlRrZEOkBUffzoq04OGGAH7DrDsh1DQSpUid3UWtYpFO6qhhhfb wwuygQCFE4jn+IE3B1NQLmlkq8n5MO/UNFKc7r1ClsllpEBEEP9JfZN+9LfOkwpL rcVEWUTqgGDtEJlsFoF5SRxMSTGK9PLpJj05P8heRggdj1G/n3cy8IUu/r0UJylY gFgpVXt86Ynwu5G147b/fRq0Rync9WeJ/dK55LJH88iEyrlS6kK8FH5B8cWx72Jo h7opXyMpUJlRWp/0cBze8uaFIt+F6pgaPxgKZURrNkYKCLthMVdkQ0N2clF9H/7z Abig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1695509149; x=1695595549; bh=SKukJsMAtn0ZO 4R01C6lpu2DbBMqwdwX7I/0rIOpOUA=; b=Z/iY1ygySB1YHKuzH81Veyrziejdg J9PwYZzXTC7XSJtMT4KfkJtkfYFAsdnH+2f94JP8gpijM8xRUAfOAaGxXfOv//MZ aR+hHDhKk1VkmIZ6qRwRGDUOf+M/4Vj5CJ7rNdDyUKE7KFq49akh52FQjU5K0rvb cA3z5XQhpgW1iElD0qbTsZdJYCO7qEeV7oP8z9OfXyhQ08wers6ILaGNtQG9irpr SuNtErSaJA76BC3ps5yt0TutbUVplFYzPQXRPqzU1ZSoZhY3lcVagsqu51mp3Eh4 ovITuZ4Rg0NI8POWWGN67xfps3gb8Y7YGrunki6R3TkahvR/XorVZOk6Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeluddgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuhffvfhgjsehmtderredtfeejnecuhfhrohhmpeffmhhithhr hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg hrnhepveeghedvudegjeeigeeujefftdffieehtdejtdevgfevheeiueeuteffffefiefg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih htrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 23 Sep 2023 18:45:47 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------DyANkJr4Sjysej9e6FAKU5xu" Message-ID: <5671e412-a23f-2d86-1e8d-985946685eca@gutov.dev> Date: Sun, 24 Sep 2023 01:45:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#66020: [PATCH] Reduce GC churn in read_process_output Content-Language: en-US From: Dmitry Gutov To: 66020@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier , Stefan Kangas References: <3a6287c3-8458-663e-ffce-8f48b30bf73d@gutov.dev> In-Reply-To: <3a6287c3-8458-663e-ffce-8f48b30bf73d@gutov.dev> X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 66020 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.2 (---) This is a multi-part message in MIME format. --------------DyANkJr4Sjysej9e6FAKU5xu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Here are the previously discussed patches, collected in one place for easier review. As explained, the last one is more experimental, a possible alternative to bumping read-process-output-max to 65536. --------------DyANkJr4Sjysej9e6FAKU5xu Content-Type: text/x-patch; charset=UTF-8; name="0001-Go-around-calling-the-default-process-filter-reducin.patch" Content-Disposition: attachment; filename*0="0001-Go-around-calling-the-default-process-filter-reducin.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSAwMDgyZmNlNDViNjc3ZjdmOTJkMWE0Y2JhYzViMTJiNzYzOTQxYWQyIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEbWl0cnkgR3V0b3YgPGRtaXRyeUBndXRvdi5kZXY+ CkRhdGU6IFN1biwgMjQgU2VwIDIwMjMgMDE6MTk6MTQgKzAzMDAKU3ViamVjdDogW1BBVENI IDEvM10gR28gYXJvdW5kIGNhbGxpbmcgdGhlIGRlZmF1bHQgcHJvY2VzcyBmaWx0ZXIgKHJl ZHVjaW5nIEdDCiBjaHVybikKCkluc3RlYWQgb2YgYWxsb2NhdGluZyBzdHJpbmdzIGFuZCBw YXNzaW5nIHRoZW0gdG8gdGhlIGZpbHRlciwgcGFzc2luZwp0aGUgY2hhciBidWZmZXIgdG8g YSBDIGZ1bmN0aW9uIGltcGxlbWVudGluZyB0aGUgc2FtZSBsb2dpYy4KCiogc3JjL3Byb2Nl c3MuYyAocmVhZF9wcm9jZXNzX291dHB1dF9iZWZvcmVfaW5zZXJ0KQoocmVhZF9wcm9jZXNz X291dHB1dF9hZnRlcl9pbnNlcnQpOiBOZXcgZnVuY3Rpb25zLCBleHRyYWN0ZWQgZnJvbQpp bnRlcm5hbC1kZWZhdWx0LXByb2Nlc3MtZmlsdGVyLgooRmludGVybmFsX2RlZmF1bHRfcHJv Y2Vzc19maWx0ZXIpOiBVc2UgdGhlbS4KKHJlYWRfYW5kX2luc2VydF9wcm9jZXNzX291dHB1 dCk6IE5ldyBmdW5jdGlvbi4gIFVzZSB0aGVtLgoocmVhZF9wcm9jZXNzX291dHB1dF9mYXN0 KTogTmV3IHZhcmlhYmxlLgoocmVhZF9wcm9jZXNzX291dHB1dCk6IFVzZSBpdCB0byBjaG9v c2UgaG93IHRvIGluc2VydCAoYnVnIzY2MDIwKS4KLS0tCiBzcmMvcHJvY2Vzcy5jIHwgMTk4 ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tCiAx IGZpbGUgY2hhbmdlZCwgMTQzIGluc2VydGlvbnMoKyksIDU1IGRlbGV0aW9ucygtKQoKZGlm ZiAtLWdpdCBhL3NyYy9wcm9jZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IDIzNzZkMGYy ODhkLi5lOTMyZWNmN2U0MyAxMDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9zcmMv cHJvY2Vzcy5jCkBAIC02MTEzLDYgKzYxMTMsMTEgQEAgcmVhZF9hbmRfZGlzcG9zZV9vZl9w cm9jZXNzX291dHB1dCAoc3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqY2hhcnMsCiAJ CQkJICAgIHNzaXplX3QgbmJ5dGVzLAogCQkJCSAgICBzdHJ1Y3QgY29kaW5nX3N5c3RlbSAq Y29kaW5nKTsKIAorc3RhdGljIHZvaWQKK3JlYWRfYW5kX2luc2VydF9wcm9jZXNzX291dHB1 dCAoc3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqYnVmLAorCQkJCSAgICBzc2l6ZV90 IG5yZWFkLAorCQkJCXN0cnVjdCBjb2Rpbmdfc3lzdGVtICpwcm9jZXNzX2NvZGluZyk7CisK IC8qIFJlYWQgcGVuZGluZyBvdXRwdXQgZnJvbSB0aGUgcHJvY2VzcyBjaGFubmVsLAogICAg c3RhcnRpbmcgd2l0aCBvdXIgYnVmZmVyZWQtYWhlYWQgY2hhcmFjdGVyIGlmIHdlIGhhdmUg b25lLgogICAgWWllbGQgbnVtYmVyIG9mIGRlY29kZWQgY2hhcmFjdGVycyByZWFkLApAQCAt NjIyOCw3ICs2MjMzLDEwIEBAIHJlYWRfcHJvY2Vzc19vdXRwdXQgKExpc3BfT2JqZWN0IHBy b2MsIGludCBjaGFubmVsKQogICAgICBmcmllbmRzIGRvbid0IGV4cGVjdCBjdXJyZW50LWJ1 ZmZlciB0byBiZSBjaGFuZ2VkIGZyb20gdW5kZXIgdGhlbS4gICovCiAgIHJlY29yZF91bndp bmRfY3VycmVudF9idWZmZXIgKCk7CiAKLSAgcmVhZF9hbmRfZGlzcG9zZV9vZl9wcm9jZXNz X291dHB1dCAocCwgY2hhcnMsIG5ieXRlcywgY29kaW5nKTsKKyAgaWYgKHAtPmZpbHRlciA9 PSBRaW50ZXJuYWxfZGVmYXVsdF9wcm9jZXNzX2ZpbHRlcikKKyAgICByZWFkX2FuZF9pbnNl cnRfcHJvY2Vzc19vdXRwdXQgKHAsIGNoYXJzLCBuYnl0ZXMsIGNvZGluZyk7CisgIGVsc2UK KyAgICByZWFkX2FuZF9kaXNwb3NlX29mX3Byb2Nlc3Nfb3V0cHV0IChwLCBjaGFycywgbmJ5 dGVzLCBjb2RpbmcpOwogCiAgIC8qIEhhbmRsaW5nIHRoZSBwcm9jZXNzIG91dHB1dCBzaG91 bGQgbm90IGRlYWN0aXZhdGUgdGhlIG1hcmsuICAqLwogICBWZGVhY3RpdmF0ZV9tYXJrID0g b2RlYWN0aXZhdGU7CkBAIC02MjM3LDYgKzYyNDUsMTI4IEBAIHJlYWRfcHJvY2Vzc19vdXRw dXQgKExpc3BfT2JqZWN0IHByb2MsIGludCBjaGFubmVsKQogICByZXR1cm4gbmJ5dGVzOwog fQogCitzdGF0aWMgdm9pZAorcmVhZF9wcm9jZXNzX291dHB1dF9iZWZvcmVfaW5zZXJ0IChz dHJ1Y3QgTGlzcF9Qcm9jZXNzICpwLCBMaXNwX09iamVjdCAqb2xkX3JlYWRfb25seSwKKwkJ CQkgICBwdHJkaWZmX3QgKm9sZF9iZWd2LCBwdHJkaWZmX3QgKm9sZF96diwKKwkJCQkgICBw dHJkaWZmX3QgKmJlZm9yZSwgcHRyZGlmZl90ICpiZWZvcmVfYnl0ZSwKKwkJCQkgICBwdHJk aWZmX3QgKm9wb2ludCwgcHRyZGlmZl90ICpvcG9pbnRfYnl0ZSkKK3sKKyAgRnNldF9idWZm ZXIgKHAtPmJ1ZmZlcik7CisgICpvcG9pbnQgPSBQVDsKKyAgKm9wb2ludF9ieXRlID0gUFRf QllURTsKKyAgKm9sZF9yZWFkX29ubHkgPSBCVkFSIChjdXJyZW50X2J1ZmZlciwgcmVhZF9v bmx5KTsKKyAgKm9sZF9iZWd2ID0gQkVHVjsKKyAgKm9sZF96diA9IFpWOworCisgIGJzZXRf cmVhZF9vbmx5IChjdXJyZW50X2J1ZmZlciwgUW5pbCk7CisKKyAgLyogSW5zZXJ0IG5ldyBv dXRwdXQgaW50byBidWZmZXIgYXQgdGhlIGN1cnJlbnQgZW5kLW9mLW91dHB1dAorICAgICBt YXJrZXIsIHRodXMgcHJlc2VydmluZyBsb2dpY2FsIG9yZGVyaW5nIG9mIGlucHV0IGFuZCBv dXRwdXQuICAqLworICBpZiAoWE1BUktFUiAocC0+bWFyayktPmJ1ZmZlcikKKyAgICBzZXRf cG9pbnRfZnJvbV9tYXJrZXIgKHAtPm1hcmspOworICBlbHNlCisgICAgU0VUX1BUX0JPVEgg KFpWLCBaVl9CWVRFKTsKKyAgKmJlZm9yZSA9IFBUOworICAqYmVmb3JlX2J5dGUgPSBQVF9C WVRFOworCisgIC8qIElmIHRoZSBvdXRwdXQgbWFya2VyIGlzIG91dHNpZGUgb2YgdGhlIHZp c2libGUgcmVnaW9uLCBzYXZlCisgICAgIHRoZSByZXN0cmljdGlvbiBhbmQgd2lkZW4uICAq LworICBpZiAoISAoQkVHViA8PSBQVCAmJiBQVCA8PSBaVikpCisgICAgRndpZGVuICgpOwor fQorCitzdGF0aWMgdm9pZAorcmVhZF9wcm9jZXNzX291dHB1dF9hZnRlcl9pbnNlcnQgKHN0 cnVjdCBMaXNwX1Byb2Nlc3MgKnAsIExpc3BfT2JqZWN0ICpvbGRfcmVhZF9vbmx5LAorCQkJ CSAgcHRyZGlmZl90IG9sZF9iZWd2LCBwdHJkaWZmX3Qgb2xkX3p2LAorCQkJCSAgcHRyZGlm Zl90IGJlZm9yZSwgcHRyZGlmZl90IGJlZm9yZV9ieXRlLAorCQkJCSAgcHRyZGlmZl90IG9w b2ludCwgcHRyZGlmZl90IG9wb2ludF9ieXRlKQoreworICBzdHJ1Y3QgYnVmZmVyICpiOwor CisgIC8qIE1ha2Ugc3VyZSB0aGUgcHJvY2VzcyBtYXJrZXIncyBwb3NpdGlvbiBpcyB2YWxp ZCB3aGVuIHRoZQorICAgICBwcm9jZXNzIGJ1ZmZlciBpcyBjaGFuZ2VkIGluIHRoZSBzaWdu YWxfYWZ0ZXJfY2hhbmdlIGFib3ZlLgorICAgICBXMyBpcyBrbm93biB0byBkbyB0aGF0LiAg Ki8KKyAgaWYgKEJVRkZFUlAgKHAtPmJ1ZmZlcikKKyAgICAgICYmIChiID0gWEJVRkZFUiAo cC0+YnVmZmVyKSwgYiAhPSBjdXJyZW50X2J1ZmZlcikpCisgICAgc2V0X21hcmtlcl9ib3Ro IChwLT5tYXJrLCBwLT5idWZmZXIsIEJVRl9QVCAoYiksIEJVRl9QVF9CWVRFIChiKSk7Cisg IGVsc2UKKyAgICBzZXRfbWFya2VyX2JvdGggKHAtPm1hcmssIHAtPmJ1ZmZlciwgUFQsIFBU X0JZVEUpOworCisgIHVwZGF0ZV9tb2RlX2xpbmVzID0gMjM7CisKKyAgLyogTWFrZSBzdXJl IG9wb2ludCBhbmQgdGhlIG9sZCByZXN0cmljdGlvbnMKKyAgICAgZmxvYXQgYWhlYWQgb2Yg YW55IG5ldyB0ZXh0IGp1c3QgYXMgcG9pbnQgd291bGQuICAqLworICBpZiAob3BvaW50ID49 IGJlZm9yZSkKKyAgICB7CisgICAgICBvcG9pbnQgKz0gUFQgLSBiZWZvcmU7CisgICAgICBv cG9pbnRfYnl0ZSArPSBQVF9CWVRFIC0gYmVmb3JlX2J5dGU7CisgICAgfQorICBpZiAob2xk X2JlZ3YgPiBiZWZvcmUpCisgICAgb2xkX2JlZ3YgKz0gUFQgLSBiZWZvcmU7CisgIGlmIChv bGRfenYgPj0gYmVmb3JlKQorICAgIG9sZF96diArPSBQVCAtIGJlZm9yZTsKKworICAvKiBJ ZiB0aGUgcmVzdHJpY3Rpb24gaXNuJ3Qgd2hhdCBpdCBzaG91bGQgYmUsIHNldCBpdC4gICov CisgIGlmIChvbGRfYmVndiAhPSBCRUdWIHx8IG9sZF96diAhPSBaVikKKyAgICBGbmFycm93 X3RvX3JlZ2lvbiAobWFrZV9maXhudW0gKG9sZF9iZWd2KSwgbWFrZV9maXhudW0gKG9sZF96 dikpOworCisgIGJzZXRfcmVhZF9vbmx5IChjdXJyZW50X2J1ZmZlciwgKm9sZF9yZWFkX29u bHkpOworICBTRVRfUFRfQk9USCAob3BvaW50LCBvcG9pbnRfYnl0ZSk7Cit9CisKK3N0YXRp YyB2b2lkIHJlYWRfYW5kX2luc2VydF9wcm9jZXNzX291dHB1dCAoc3RydWN0IExpc3BfUHJv Y2VzcyAqcCwgY2hhciAqYnVmLAorCQkJCSAgICBzc2l6ZV90IG5yZWFkLAorCQkJCSAgICBz dHJ1Y3QgY29kaW5nX3N5c3RlbSAqcHJvY2Vzc19jb2RpbmcpCit7CisgIGlmICghbnJlYWQg fHwgTklMUCAocC0+YnVmZmVyKSB8fCAhQlVGRkVSX0xJVkVfUCAoWEJVRkZFUiAocC0+YnVm ZmVyKSkpCisgICAgcmV0dXJuOworCisgIExpc3BfT2JqZWN0IG9sZF9yZWFkX29ubHk7Cisg IHB0cmRpZmZfdCBvbGRfYmVndiwgb2xkX3p2OworICBwdHJkaWZmX3QgYmVmb3JlLCBiZWZv cmVfYnl0ZTsKKyAgcHRyZGlmZl90IG9wb2ludCwgb3BvaW50X2J5dGU7CisKKyAgcmVhZF9w cm9jZXNzX291dHB1dF9iZWZvcmVfaW5zZXJ0IChwLCAmb2xkX3JlYWRfb25seSwgJm9sZF9i ZWd2LCAmb2xkX3p2LAorCQkJCSAgICAgJmJlZm9yZSwgJmJlZm9yZV9ieXRlLCAmb3BvaW50 LCAmb3BvaW50X2J5dGUpOworCisgIC8qIEFkYXB0ZWQgZnJvbSBjYWxsX3Byb2Nlc3MuICAq LworICBpZiAoTklMUCAoQlZBUiAoWEJVRkZFUihwLT5idWZmZXIpLCBlbmFibGVfbXVsdGli eXRlX2NoYXJhY3RlcnMpKQorCSAgICYmICEgQ09ESU5HX01BWV9SRVFVSVJFX0RFQ09ESU5H IChwcm9jZXNzX2NvZGluZykpCisgICAgeworICAgICAgaW5zZXJ0XzFfYm90aCAoYnVmLCBu cmVhZCwgbnJlYWQsIDAsIDAsIDApOworICAgICAgc2lnbmFsX2FmdGVyX2NoYW5nZSAoUFQg LSBucmVhZCwgMCwgbnJlYWQpOworICAgIH0KKyAgZWxzZQorICAgIHsJCQkvKiBXZSBoYXZl IHRvIGRlY29kZSB0aGUgaW5wdXQuICAqLworICAgICAgTGlzcF9PYmplY3QgY3VyYnVmOwor ICAgICAgaW50IGNhcnJ5b3ZlciA9IDA7CisgICAgICBzcGVjcGRsX3JlZiBjb3VudDEgPSBT UEVDUERMX0lOREVYICgpOworCisgICAgICBYU0VUQlVGRkVSIChjdXJidWYsIGN1cnJlbnRf YnVmZmVyKTsKKyAgICAgIC8qIFdlIGNhbm5vdCBhbGxvdyBhZnRlci1jaGFuZ2UtZnVuY3Rp b25zIGJlIHJ1bgorCSBkdXJpbmcgZGVjb2RpbmcsIGJlY2F1c2UgdGhhdCBtaWdodCBtb2Rp ZnkgdGhlCisJIGJ1ZmZlciwgd2hpbGUgd2UgcmVseSBvbiBwcm9jZXNzX2NvZGluZy5wcm9k dWNlZCB0bworCSBmYWl0aGZ1bGx5IHJlZmxlY3QgaW5zZXJ0ZWQgdGV4dCB1bnRpbCB3ZQor CSBURU1QX1NFVF9QVF9CT1RIIGJlbG93LiAgKi8KKyAgICAgIHNwZWNiaW5kIChRaW5oaWJp dF9tb2RpZmljYXRpb25faG9va3MsIFF0KTsKKyAgICAgIGRlY29kZV9jb2RpbmdfY19zdHJp bmcgKHByb2Nlc3NfY29kaW5nLAorCQkJICAgICAgKHVuc2lnbmVkIGNoYXIgKikgYnVmLCBu cmVhZCwgY3VyYnVmKTsKKyAgICAgIHVuYmluZF90byAoY291bnQxLCBRbmlsKTsKKworICAg ICAgVEVNUF9TRVRfUFRfQk9USCAoUFQgKyBwcm9jZXNzX2NvZGluZy0+cHJvZHVjZWRfY2hh ciwKKwkJCVBUX0JZVEUgKyBwcm9jZXNzX2NvZGluZy0+cHJvZHVjZWQpOworICAgICAgc2ln bmFsX2FmdGVyX2NoYW5nZSAoUFQgLSBwcm9jZXNzX2NvZGluZy0+cHJvZHVjZWRfY2hhciwK KwkJCSAgIDAsIHByb2Nlc3NfY29kaW5nLT5wcm9kdWNlZF9jaGFyKTsKKyAgICAgIGNhcnJ5 b3ZlciA9IHByb2Nlc3NfY29kaW5nLT5jYXJyeW92ZXJfYnl0ZXM7CisgICAgICBpZiAoY2Fy cnlvdmVyID4gMCkKKwltZW1jcHkgKGJ1ZiwgcHJvY2Vzc19jb2RpbmctPmNhcnJ5b3ZlciwK KwkJcHJvY2Vzc19jb2RpbmctPmNhcnJ5b3Zlcl9ieXRlcyk7CisgICAgfQorCisgIHJlYWRf cHJvY2Vzc19vdXRwdXRfYWZ0ZXJfaW5zZXJ0IChwLCAmb2xkX3JlYWRfb25seSwgb2xkX2Jl Z3YsIG9sZF96diwKKwkJCQkgICAgYmVmb3JlLCBiZWZvcmVfYnl0ZSwgb3BvaW50LCBvcG9p bnRfYnl0ZSk7Cit9CisKIHN0YXRpYyB2b2lkCiByZWFkX2FuZF9kaXNwb3NlX29mX3Byb2Nl c3Nfb3V0cHV0IChzdHJ1Y3QgTGlzcF9Qcm9jZXNzICpwLCBjaGFyICpjaGFycywKIAkJCQkg ICAgc3NpemVfdCBuYnl0ZXMsCkBAIC02MzQwLDcgKzY0NzAsNiBAQCBERUZVTiAoImludGVy bmFsLWRlZmF1bHQtcHJvY2Vzcy1maWx0ZXIiLCBGaW50ZXJuYWxfZGVmYXVsdF9wcm9jZXNz X2ZpbHRlciwKICAgKExpc3BfT2JqZWN0IHByb2MsIExpc3BfT2JqZWN0IHRleHQpCiB7CiAg IHN0cnVjdCBMaXNwX1Byb2Nlc3MgKnA7Ci0gIHB0cmRpZmZfdCBvcG9pbnQ7CiAKICAgQ0hF Q0tfUFJPQ0VTUyAocHJvYyk7CiAgIHAgPSBYUFJPQ0VTUyAocHJvYyk7CkBAIC02MzUxLDMx ICs2NDgwLDEwIEBAIERFRlVOICgiaW50ZXJuYWwtZGVmYXVsdC1wcm9jZXNzLWZpbHRlciIs IEZpbnRlcm5hbF9kZWZhdWx0X3Byb2Nlc3NfZmlsdGVyLAogICAgICAgTGlzcF9PYmplY3Qg b2xkX3JlYWRfb25seTsKICAgICAgIHB0cmRpZmZfdCBvbGRfYmVndiwgb2xkX3p2OwogICAg ICAgcHRyZGlmZl90IGJlZm9yZSwgYmVmb3JlX2J5dGU7Ci0gICAgICBwdHJkaWZmX3Qgb3Bv aW50X2J5dGU7Ci0gICAgICBzdHJ1Y3QgYnVmZmVyICpiOwotCi0gICAgICBGc2V0X2J1ZmZl ciAocC0+YnVmZmVyKTsKLSAgICAgIG9wb2ludCA9IFBUOwotICAgICAgb3BvaW50X2J5dGUg PSBQVF9CWVRFOwotICAgICAgb2xkX3JlYWRfb25seSA9IEJWQVIgKGN1cnJlbnRfYnVmZmVy LCByZWFkX29ubHkpOwotICAgICAgb2xkX2JlZ3YgPSBCRUdWOwotICAgICAgb2xkX3p2ID0g WlY7Ci0KLSAgICAgIGJzZXRfcmVhZF9vbmx5IChjdXJyZW50X2J1ZmZlciwgUW5pbCk7Ci0K LSAgICAgIC8qIEluc2VydCBuZXcgb3V0cHV0IGludG8gYnVmZmVyIGF0IHRoZSBjdXJyZW50 IGVuZC1vZi1vdXRwdXQKLQkgbWFya2VyLCB0aHVzIHByZXNlcnZpbmcgbG9naWNhbCBvcmRl cmluZyBvZiBpbnB1dCBhbmQgb3V0cHV0LiAgKi8KLSAgICAgIGlmIChYTUFSS0VSIChwLT5t YXJrKS0+YnVmZmVyKQotCXNldF9wb2ludF9mcm9tX21hcmtlciAocC0+bWFyayk7Ci0gICAg ICBlbHNlCi0JU0VUX1BUX0JPVEggKFpWLCBaVl9CWVRFKTsKLSAgICAgIGJlZm9yZSA9IFBU OwotICAgICAgYmVmb3JlX2J5dGUgPSBQVF9CWVRFOworICAgICAgcHRyZGlmZl90IG9wb2lu dCwgb3BvaW50X2J5dGU7CiAKLSAgICAgIC8qIElmIHRoZSBvdXRwdXQgbWFya2VyIGlzIG91 dHNpZGUgb2YgdGhlIHZpc2libGUgcmVnaW9uLCBzYXZlCi0JIHRoZSByZXN0cmljdGlvbiBh bmQgd2lkZW4uICAqLwotICAgICAgaWYgKCEgKEJFR1YgPD0gUFQgJiYgUFQgPD0gWlYpKQot CUZ3aWRlbiAoKTsKKyAgICAgIHJlYWRfcHJvY2Vzc19vdXRwdXRfYmVmb3JlX2luc2VydCAo cCwgJm9sZF9yZWFkX29ubHksICZvbGRfYmVndiwgJm9sZF96diwKKwkJCQkJICZiZWZvcmUs ICZiZWZvcmVfYnl0ZSwgJm9wb2ludCwgJm9wb2ludF9ieXRlKTsKIAogICAgICAgLyogQWRq dXN0IHRoZSBtdWx0aWJ5dGVuZXNzIG9mIFRFWFQgdG8gdGhhdCBvZiB0aGUgYnVmZmVyLiAg Ki8KICAgICAgIGlmIChOSUxQIChCVkFSIChjdXJyZW50X2J1ZmZlciwgZW5hYmxlX211bHRp Ynl0ZV9jaGFyYWN0ZXJzKSkKQEAgLTYzODgsMzUgKzY0OTYsOCBAQCBERUZVTiAoImludGVy bmFsLWRlZmF1bHQtcHJvY2Vzcy1maWx0ZXIiLCBGaW50ZXJuYWxfZGVmYXVsdF9wcm9jZXNz X2ZpbHRlciwKICAgICAgIGluc2VydF9mcm9tX3N0cmluZ19iZWZvcmVfbWFya2VycyAodGV4 dCwgMCwgMCwKIAkJCQkJIFNDSEFSUyAodGV4dCksIFNCWVRFUyAodGV4dCksIDApOwogCi0g ICAgICAvKiBNYWtlIHN1cmUgdGhlIHByb2Nlc3MgbWFya2VyJ3MgcG9zaXRpb24gaXMgdmFs aWQgd2hlbiB0aGUKLQkgcHJvY2VzcyBidWZmZXIgaXMgY2hhbmdlZCBpbiB0aGUgc2lnbmFs X2FmdGVyX2NoYW5nZSBhYm92ZS4KLQkgVzMgaXMga25vd24gdG8gZG8gdGhhdC4gICovCi0g ICAgICBpZiAoQlVGRkVSUCAocC0+YnVmZmVyKQotCSAgJiYgKGIgPSBYQlVGRkVSIChwLT5i dWZmZXIpLCBiICE9IGN1cnJlbnRfYnVmZmVyKSkKLQlzZXRfbWFya2VyX2JvdGggKHAtPm1h cmssIHAtPmJ1ZmZlciwgQlVGX1BUIChiKSwgQlVGX1BUX0JZVEUgKGIpKTsKLSAgICAgIGVs c2UKLQlzZXRfbWFya2VyX2JvdGggKHAtPm1hcmssIHAtPmJ1ZmZlciwgUFQsIFBUX0JZVEUp OwotCi0gICAgICB1cGRhdGVfbW9kZV9saW5lcyA9IDIzOwotCi0gICAgICAvKiBNYWtlIHN1 cmUgb3BvaW50IGFuZCB0aGUgb2xkIHJlc3RyaWN0aW9ucwotCSBmbG9hdCBhaGVhZCBvZiBh bnkgbmV3IHRleHQganVzdCBhcyBwb2ludCB3b3VsZC4gICovCi0gICAgICBpZiAob3BvaW50 ID49IGJlZm9yZSkKLQl7Ci0JICBvcG9pbnQgKz0gUFQgLSBiZWZvcmU7Ci0JICBvcG9pbnRf Ynl0ZSArPSBQVF9CWVRFIC0gYmVmb3JlX2J5dGU7Ci0JfQotICAgICAgaWYgKG9sZF9iZWd2 ID4gYmVmb3JlKQotCW9sZF9iZWd2ICs9IFBUIC0gYmVmb3JlOwotICAgICAgaWYgKG9sZF96 diA+PSBiZWZvcmUpCi0Jb2xkX3p2ICs9IFBUIC0gYmVmb3JlOwotCi0gICAgICAvKiBJZiB0 aGUgcmVzdHJpY3Rpb24gaXNuJ3Qgd2hhdCBpdCBzaG91bGQgYmUsIHNldCBpdC4gICovCi0g ICAgICBpZiAob2xkX2JlZ3YgIT0gQkVHViB8fCBvbGRfenYgIT0gWlYpCi0JRm5hcnJvd190 b19yZWdpb24gKG1ha2VfZml4bnVtIChvbGRfYmVndiksIG1ha2VfZml4bnVtIChvbGRfenYp KTsKLQotICAgICAgYnNldF9yZWFkX29ubHkgKGN1cnJlbnRfYnVmZmVyLCBvbGRfcmVhZF9v bmx5KTsKLSAgICAgIFNFVF9QVF9CT1RIIChvcG9pbnQsIG9wb2ludF9ieXRlKTsKKyAgICAg IHJlYWRfcHJvY2Vzc19vdXRwdXRfYWZ0ZXJfaW5zZXJ0IChwLCAmb2xkX3JlYWRfb25seSwg b2xkX2JlZ3YsIG9sZF96diwKKwkJCQkJYmVmb3JlLCBiZWZvcmVfYnl0ZSwgb3BvaW50LCBv cG9pbnRfYnl0ZSk7CiAgICAgfQogICByZXR1cm4gUW5pbDsKIH0KQEAgLTg3NjQsNiArODg0 NSwxMyBAQCBzeW1zX29mX3Byb2Nlc3MgKHZvaWQpCiAvcHJvYy9zeXMvZnMvcGlwZS1tYXgt c2l6ZS4gIFNlZSBwaXBlKDcpIG1hbnBhZ2UgZm9yIGRldGFpbHMuICAqLyk7CiAgIHJlYWRf cHJvY2Vzc19vdXRwdXRfbWF4ID0gNDA5NjsKIAorICBERUZWQVJfQk9PTCAoInJlYWQtcHJv Y2Vzcy1vdXRwdXQtZmFzdCIsIHJlYWRfcHJvY2Vzc19vdXRwdXRfZmFzdCwKKwkgICAgICAg ZG9jOiAvKiBOb24tbmlsIHRvIG9wdGltaXplIHRoZSBpbnNlcnRpb24gb2YgcHJvY2VzcyBv dXRwdXQuCitXZSBza2lwIGNhbGxpbmcgYGludGVybmFsLWRlZmF1bHQtcHJvY2Vzcy1maWx0 ZXInIGFuZCBkb24ndCBhbGxvY2F0ZQordGhlIExpc3Agc3RyaW5nIHRoYXQgd291bGQgYmUg dXNlZCBhcyBpdHMgYXJndW1lbnQuICBPbmx5IGFmZmVjdHMgdGhlCitjYXNlIG9mIGFzeW5j aHJvbm91cyBwcm9jZXNzIHdpdGggdGhlIGRlZmF1bHQgZmlsdGVyLiAgKi8pOworICByZWFk X3Byb2Nlc3Nfb3V0cHV0X2Zhc3QgPSBRdDsKKwogICBERUZWQVJfSU5UICgicHJvY2Vzcy1l cnJvci1wYXVzZS10aW1lIiwgcHJvY2Vzc19lcnJvcl9wYXVzZV90aW1lLAogCSAgICAgIGRv YzogLyogVGhlIG51bWJlciBvZiBzZWNvbmRzIHRvIHBhdXNlIGFmdGVyIGhhbmRsaW5nIHBy b2Nlc3MgZXJyb3JzLgogVGhpcyBpc24ndCB1c2VkIGZvciBhbGwgcHJvY2Vzcy1yZWxhdGVk IGVycm9ycywgYnV0IGlzIHVzZWQgd2hlbiBhCi0tIAoyLjM3LjIKCg== --------------DyANkJr4Sjysej9e6FAKU5xu Content-Type: text/x-patch; charset=UTF-8; name="0002-Remember-the-value-of-read_process_output_max-when-a.patch" Content-Disposition: attachment; filename*0="0002-Remember-the-value-of-read_process_output_max-when-a.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSBiYzM5OTZmNzI3NTc4MDk3MGQyZDVkYzUzZGEyZmQ1YThjYWFkMWU0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEbWl0cnkgR3V0b3YgPGRtaXRyeUBndXRvdi5kZXY+ CkRhdGU6IFN1biwgMjQgU2VwIDIwMjMgMDE6MjQ6MTkgKzAzMDAKU3ViamVjdDogW1BBVENI IDIvM10gUmVtZW1iZXIgdGhlIHZhbHVlIG9mIHJlYWRfcHJvY2Vzc19vdXRwdXRfbWF4IHdo ZW4gYQogcHJvY2VzcyBpcyBjcmVhdGVkCgoqIHNyYy9wcm9jZXNzLmMgKHJlYWRfcHJvY2Vz c19vdXRwdXQpOiBVc2UgaXQuCihjcmVhdGVfcHJvY2Vzcyk6IFNhdmUgdGhlIHZhbHVlIG9m IHJlYWRfcHJvY2Vzc19vdXRwdXRfbWF4IHRvIGl0IHdoZW4KdGhlIHByb2Nlc3MgaXMgY3Jl YXRlZCAoYnVnIzY2MDIwKS4KKGNyZWF0ZV9wcm9jZXNzKTogTWFrZSBzdXJlIG5vdCB0byBy ZWR1Y2UgdGhlIHBpcGUncyBidWZmZXIsIG9ubHkKaW5jcmVhc2UgaXQgaWYgb3VyIHZhbHVl IGlzIGhpZ2hlciB0aGFuIHRoZSBvbmUgc2V0IGJ5IHRoZSBPUy4KCiogc3JjL3Byb2Nlc3Mu aCAoTGlzcF9Qcm9jZXNzKTogQWRkIGZpZWxkIHJlYWRtYXguCi0tLQogc3JjL3Byb2Nlc3Mu YyB8IDcgKysrKystLQogc3JjL3Byb2Nlc3MuaCB8IDIgKysKIDIgZmlsZXMgY2hhbmdlZCwg NyBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9wcm9j ZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IGU5MzJlY2Y3ZTQzLi5kN2FlZGNkZjEyZCAx MDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9zcmMvcHJvY2Vzcy5jCkBAIC0yMTkz LDYgKzIxOTMsOCBAQCBjcmVhdGVfcHJvY2VzcyAoTGlzcF9PYmplY3QgcHJvY2VzcywgY2hh ciAqKm5ld19hcmd2LCBMaXNwX09iamVjdCBjdXJyZW50X2RpcikKICAgICAgIG91dGNoYW5u ZWwgPSBwLT5vcGVuX2ZkW1dSSVRFX1RPX1NVQlBST0NFU1NdOwogICAgIH0KIAorICBwLT5y ZWFkbWF4ID0gY2xpcF90b19ib3VuZHMgKDEsIHJlYWRfcHJvY2Vzc19vdXRwdXRfbWF4LCBQ VFJESUZGX01BWCk7CisKICAgLyogU2V0IHVwIHN0ZG91dCBmb3IgdGhlIGNoaWxkIHByb2Nl c3MuICAqLwogICBpZiAocHR5Y2hhbm5lbCA+PSAwICYmIHAtPnB0eV9vdXQpCiAgICAgewpA QCAtMjIwOCw3ICsyMjEwLDggQEAgY3JlYXRlX3Byb2Nlc3MgKExpc3BfT2JqZWN0IHByb2Nl c3MsIGNoYXIgKipuZXdfYXJndiwgTGlzcF9PYmplY3QgY3VycmVudF9kaXIpCiAKICNpZiAo ZGVmaW5lZCAoR05VX0xJTlVYKSB8fCBkZWZpbmVkIF9fQU5EUk9JRF9fKQlcCiAgICYmIGRl ZmluZWQgKEZfU0VUUElQRV9TWikKLSAgICAgIGZjbnRsIChpbmNoYW5uZWwsIEZfU0VUUElQ RV9TWiwgcmVhZF9wcm9jZXNzX291dHB1dF9tYXgpOworICAgICAgaWYgKHAtPnJlYWRtYXgg PiBmY250bCAoaW5jaGFubmVsLCBGX0dFVFBJUEVfU1osIHJlYWRfcHJvY2Vzc19vdXRwdXRf bWF4KSkKKwlmY250bCAoaW5jaGFubmVsLCBGX1NFVFBJUEVfU1osIHAtPnJlYWRtYXgpOwog I2VuZGlmIC8qIChHTlVfTElOVVggfHwgX19BTkRST0lEX18pICYmIEZfU0VUUElQRV9TWiAq LwogICAgIH0KIApAQCAtNjEzOCw3ICs2MTQxLDcgQEAgcmVhZF9wcm9jZXNzX291dHB1dCAo TGlzcF9PYmplY3QgcHJvYywgaW50IGNoYW5uZWwpCiAgIGVhc3NlcnQgKDAgPD0gY2hhbm5l bCAmJiBjaGFubmVsIDwgRkRfU0VUU0laRSk7CiAgIHN0cnVjdCBjb2Rpbmdfc3lzdGVtICpj b2RpbmcgPSBwcm9jX2RlY29kZV9jb2Rpbmdfc3lzdGVtW2NoYW5uZWxdOwogICBpbnQgY2Fy cnlvdmVyID0gcC0+ZGVjb2RpbmdfY2FycnlvdmVyOwotICBwdHJkaWZmX3QgcmVhZG1heCA9 IGNsaXBfdG9fYm91bmRzICgxLCByZWFkX3Byb2Nlc3Nfb3V0cHV0X21heCwgUFRSRElGRl9N QVgpOworICBwdHJkaWZmX3QgcmVhZG1heCA9IHAtPnJlYWRtYXg7CiAgIHNwZWNwZGxfcmVm IGNvdW50ID0gU1BFQ1BETF9JTkRFWCAoKTsKICAgTGlzcF9PYmplY3Qgb2RlYWN0aXZhdGU7 CiAgIGNoYXIgKmNoYXJzOwpkaWZmIC0tZ2l0IGEvc3JjL3Byb2Nlc3MuaCBiL3NyYy9wcm9j ZXNzLmgKaW5kZXggYmJlNDUyOGRjMzEuLjk4MGM3MjE2Njg5IDEwMDY0NAotLS0gYS9zcmMv cHJvY2Vzcy5oCisrKyBiL3NyYy9wcm9jZXNzLmgKQEAgLTE1Myw2ICsxNTMsOCBAQCAjZGVm aW5lIEVNQUNTX1BST0NFU1NfSAogICAgIHVuc2lnbmVkIGludCBhZGFwdGl2ZV9yZWFkX2J1 ZmZlcmluZyA6IDI7CiAgICAgLyogU2tpcCByZWFkaW5nIHRoaXMgcHJvY2VzcyBvbiBuZXh0 IHJlYWQuICAqLwogICAgIGJvb2xfYmYgcmVhZF9vdXRwdXRfc2tpcCA6IDE7CisgICAgLyog TWF4aW11bSBudW1iZXIgb2YgYnl0ZXMgdG8gcmVhZCBpbiBhIHNpbmdsZSBjaHVuay4gKi8K KyAgICBwdHJkaWZmX3QgcmVhZG1heDsKICAgICAvKiBUcnVlIG1lYW5zIGtpbGwgc2lsZW50 bHkgaWYgRW1hY3MgaXMgZXhpdGVkLgogICAgICAgIFRoaXMgaXMgdGhlIGludmVyc2Ugb2Yg dGhlIGBxdWVyeS1vbi1leGl0JyBmbGFnLiAgKi8KICAgICBib29sX2JmIGtpbGxfd2l0aG91 dF9xdWVyeSA6IDE7Ci0tIAoyLjM3LjIKCg== --------------DyANkJr4Sjysej9e6FAKU5xu Content-Type: text/x-patch; charset=UTF-8; name="0003-Dynamically-increase-the-readmax-if-the-pipe-has-mor.patch" Content-Disposition: attachment; filename*0="0003-Dynamically-increase-the-readmax-if-the-pipe-has-mor.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSBjMTMwMDM5N2Y4NmEzOTdhZTM4YWQwODEyNmRjOGUwMjEwNjdmMTI4IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEbWl0cnkgR3V0b3YgPGRtaXRyeUBndXRvdi5kZXY+ CkRhdGU6IFN1biwgMjQgU2VwIDIwMjMgMDE6Mjk6MTggKzAzMDAKU3ViamVjdDogW1BBVENI IDMvM10gRHluYW1pY2FsbHkgaW5jcmVhc2UgdGhlIHJlYWRtYXggaWYgdGhlIHBpcGUgaGFz IG1vcmUKIGF2YWlsYWJsZQoKKiBzcmMvcHJvY2Vzcy5jIChyZWFkX3Byb2Nlc3Nfb3V0cHV0 KTogRHluYW1pY2FsbHkgaW5jcmVhc2UgdGhlCmJ1ZmZlciBzaXplIGRlcGVuZGluZyBvbiB0 aGUgcGlwZSdzIGJ1ZmZlcmVkIGNvbnRlbnRzIChidWcjNjYwMjApLgotLS0KIHNyYy9wcm9j ZXNzLmMgfCAxMSArKysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDExIGluc2VydGlvbnMo KykKCmRpZmYgLS1naXQgYS9zcmMvcHJvY2Vzcy5jIGIvc3JjL3Byb2Nlc3MuYwppbmRleCBk N2FlZGNkZjEyZC4uMTNjZjZkNmM1MGQgMTAwNjQ0Ci0tLSBhL3NyYy9wcm9jZXNzLmMKKysr IGIvc3JjL3Byb2Nlc3MuYwpAQCAtNjE0Niw2ICs2MTQ2LDE3IEBAIHJlYWRfcHJvY2Vzc19v dXRwdXQgKExpc3BfT2JqZWN0IHByb2MsIGludCBjaGFubmVsKQogICBMaXNwX09iamVjdCBv ZGVhY3RpdmF0ZTsKICAgY2hhciAqY2hhcnM7CiAKKyNpZmRlZiBVU0FCTEVfRklPTlJFQUQK KyNpZmRlZiBEQVRBR1JBTV9TT0NLRVRTCisgIGlmICghREFUQUdSQU1fQ0hBTl9QIChjaGFu bmVsKSkKKyNlbmRpZgorICAgIHsKKyAgICAgIGludCBhdmFpbGFibGVfcmVhZDsKKyAgICAg IGlvY3RsIChwLT5pbmZkLCBGSU9OUkVBRCwgJmF2YWlsYWJsZV9yZWFkKTsKKyAgICAgIHJl YWRtYXggPSBNQVggKHJlYWRtYXgsIGF2YWlsYWJsZV9yZWFkKTsKKyAgICB9CisjZW5kaWYK KwogICBVU0VfU0FGRV9BTExPQ0E7CiAgIGNoYXJzID0gU0FGRV9BTExPQ0EgKHNpemVvZiBj b2RpbmctPmNhcnJ5b3ZlciArIHJlYWRtYXgpOwogCi0tIAoyLjM3LjIKCg== --------------DyANkJr4Sjysej9e6FAKU5xu-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 01:30:23 2023 Received: (at 66020) by debbugs.gnu.org; 24 Sep 2023 05:30:23 +0000 Received: from localhost ([127.0.0.1]:40883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkHhG-0002O7-NG for submit@debbugs.gnu.org; Sun, 24 Sep 2023 01:30:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkHhE-0002Nv-Gn for 66020@debbugs.gnu.org; Sun, 24 Sep 2023 01:30:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qkHgw-0006DQ-B3; Sun, 24 Sep 2023 01:30:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hx69whFCd6nyy29p7bUM4wOGv5p/g0ZvrUmpFVz56Jc=; b=mwt1xBgAA83j YEZC/tlgMM5rYCq0TqeY9og5I+BUm5/LCvBHyfmAv+DYoWEekfHFdoHcfjsNAZDuLMeqgXqin2jaP nMuegghUbsyAgHmRzxBPUTWHElHUgKbGFUIwWhI0UT/drdcLUBP4zAXo4mPYYH/UrI1rzwbwDZkoC XiV//cemEVBS0aFoI2cNw/0wgnwJYrpQ37IL0jetQ0Yl22f5IDat8UZKiwgg8Efpd6+Yf9DdgQmBI 4gHVYr+FCmZcWBN51RyqHFFAFt3Gpdg9QAeoiNn3KBptXxxyVpLUCbRWW03az6/uvHHDdJrlhvKjr uxpeUsVh8tc1R6XRilVWUg==; Date: Sun, 24 Sep 2023 08:29:37 +0300 Message-Id: <838r8w3zr2.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 24 Sep 2023 00:51:28 +0300) Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max References: <83il8lxjcu.fsf@gnu.org> <2e21ec81-8e4f-4c02-ea15-43bd6da3daa7@gutov.dev> <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: Paul Eggert , stefankangas@gmail.com, 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 24 Sep 2023 00:51:28 +0300 > From: Dmitry Gutov > Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com > > But it seems I've found an answer to one previous question: "can we find > out how much is already buffered in advance?" > > The patch below asks that from the OS (how portable is this? not sure) > and allocates a larger buffer when more output has been buffered. If we > keep OS's default value of pipe buffer size (64K on Linux and 16K-ish on > macOS, according to > https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer), > that means auto-scaling the buffer on Emacs's side depending on how much > the process outputs. The effect on performance is similar to the > previous (looping) patch (0.70 -> 0.65), and is comparable to bumping > read-process-output-max to 65536. > > So if we do decide to bump the default, I suppose the below should not > be necessary. And I don't know whether we should be concerned about > fragmentation: this way buffers do get allocates in different sizes > (almost always multiples of 4096, but with rare exceptions among larger > values). > > diff --git a/src/process.c b/src/process.c > index 2376d0f288d..13cf6d6c50d 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -6137,7 +6145,18 @@ > specpdl_ref count = SPECPDL_INDEX (); > Lisp_Object odeactivate; > char *chars; > > +#ifdef USABLE_FIONREAD > +#ifdef DATAGRAM_SOCKETS > + if (!DATAGRAM_CHAN_P (channel)) > +#endif > + { > + int available_read; > + ioctl (p->infd, FIONREAD, &available_read); > + readmax = MAX (readmax, available_read); > + } > +#endif > + > USE_SAFE_ALLOCA; > chars = SAFE_ALLOCA (sizeof coding->carryover + readmax); > > What do people think? I think we should increase the default size, and the rest (querying the system about the pipe size) looks like an unnecessary complication to me. I've added Paul Eggert to this discussion, as I'd like to hear his opinions about this stuff. From debbugs-submit-bounces@debbugs.gnu.org Sun May 26 11:20:38 2024 Received: (at 66020) by debbugs.gnu.org; 26 May 2024 15:20:38 +0000 Received: from localhost ([127.0.0.1]:42271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBFfp-0005pY-Py for submit@debbugs.gnu.org; Sun, 26 May 2024 11:20:38 -0400 Received: from wfhigh3-smtp.messagingengine.com ([64.147.123.154]:37007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBFfn-0005pJ-LP for 66020@debbugs.gnu.org; Sun, 26 May 2024 11:20:36 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id A46D518000E5; Sun, 26 May 2024 11:20:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 26 May 2024 11:20:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1716736820; x=1716823220; bh=a1KxVJm+Di2yhsxzUwmKb5u1t9iX+azdhR5336hW++o=; b= X2flwrCEKdWTcV6ENfr3EmKiBsSOuzfvBKoPEv6zeSSwoH1K1wRI9YLWQUwTunVv TK5SrZPGMNUOgWQRMgenGcB4OCqMxlXX0EEz+9okbO2VEudr4zg5xq9PZBuaHTpA MlUP6Lu+eooAaM2An758aqmiuh5aMG+wjmMyPMG44Dm1oM4y11dFSHGU6UvrmLY0 0I8dMK752gFCfsUfcQ2sOKRABJw/XMnjz1xgKGvwL5luTqUjp9a7/yz7F3DZ0dRw Qcic23Icp9LApZjgvXeOOpTULH6Xce5TL6W5zRg6vlUeVR8jzHqgnPxBrpdA+3Vn LHSlctuN0u0QagOtBnv8cA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1716736820; x= 1716823220; bh=a1KxVJm+Di2yhsxzUwmKb5u1t9iX+azdhR5336hW++o=; b=c gCqgpl+DVL6fZwxTSDZdRQdixDuYHb8WBUFV/olmmBxc9N0Jwe0VAZ8Jb/X67bjV OjwaSpd9K4opMg3NIyKkKzqoxJVDqMFoHFMnquoSKj6cvQjyxdpeJvak71i0LrzQ Zc9yhovVUtYww2OZ+dGeTn4DTJo/OvACNp32mO1TrrzS2LdoH1S8flzPJPHrMmEM SJzkQWXEkIkJNIw4LdtIgdrDj1KRvtYvLgf9wkgID4NO9BU2PIXN32DzHCXq5yBF aymsa09WjT4tgKk6s1SwK7h6R+mEx072Ylh+SvOcgS6edjSCYKCWUS0eBIqZnQan VCU3lMQRaEo1DgOBdHOKg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdejvddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 May 2024 11:20:18 -0400 (EDT) Message-ID: Date: Sun, 26 May 2024 18:20:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Eli Zaretskii , Paul Eggert References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <838r8w3zr2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66020 Cc: stefankangas@gmail.com, 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Paul and Eli, On 24/09/2023 08:29, Eli Zaretskii wrote: >> What do people think? > I think we should increase the default size, and the rest (querying > the system about the pipe size) looks like an unnecessary complication > to me. > > I've added Paul Eggert to this discussion, as I'd like to hear his > opinions about this stuff. Do you think we can get this in before the emacs-30 branch is cut? To summarize: * Patch 1 (reduces consing when the default filter is used by moving it into C - skipping the creation of Lisp strings). * Patch 2 a) It ensures that the dynamic binding of read-process-output-max is saved when the process it created and used for its processing - ensuring that the current dynamic value is not just used when creating the pipe, but also later when reading from it. b) A few lines are outdated: part of the fix went in with bug#66288. * Patch 3 can be replaced with just upping the default value of read-process-output-max to 65536. From debbugs-submit-bounces@debbugs.gnu.org Sun May 26 12:02:05 2024 Received: (at 66020) by debbugs.gnu.org; 26 May 2024 16:02:06 +0000 Received: from localhost ([127.0.0.1]:42328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBGJx-0006vM-KU for submit@debbugs.gnu.org; Sun, 26 May 2024 12:02:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBGJv-0006ur-99 for 66020@debbugs.gnu.org; Sun, 26 May 2024 12:02:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBGJg-0000x4-FZ; Sun, 26 May 2024 12:01:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=i8qSQyBFhxby8HdwHvDdQAuOgaFE+g87k0lxFse1RGw=; b=gczRBiLvzACu 3vdEMmJAhi43THeMseh9jPwnO3M+Vz9z9J9PItwxW6K9Y3x0WtSqmeM+UdlnGUy69Hz6HYpD6lxdL E9ST06VaJj+/RIVEsOL1VqU2hoEICYJtIeMNlLFDP5MUcyacQ+UpP846LuFgLKOtLMaFIYJnAGBl9 ocj4bs1dJPymbjszoLXocCXl1XlCAH23K0W7cozIe4ptBVXhhuIpA8TPOalY5ZinQuBwYVSSoM+zy bE78zjYwEMFJJM6R3hcwN7o6f0aTEwgGocQB+7wrCcp6ao/P6u/e6TIY6YkCl+qbJDkpXmx0vMDlM yFICQAzaMF9tkVw/ZDU0QQ==; Date: Sun, 26 May 2024 19:01:44 +0300 Message-Id: <868qzwwoif.fsf@gnu.org> From: Eli Zaretskii To: eggert@cs.ucla.edu, Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 26 May 2024 18:20:15 +0300) Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max References: <8334zmtwwi.fsf@gnu.org> <83tts0rkh5.fsf@gnu.org> <831qf3pd1y.fsf@gnu.org> <28a7916e-92d5-77ab-a61e-f85b59ac76b1@gutov.dev> <83sf7jnq0m.fsf@gnu.org> <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 66020 Cc: stefankangas@gmail.com, 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Date: Sun, 26 May 2024 18:20:15 +0300 > Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com > From: Dmitry Gutov > > Hi Paul and Eli, > > On 24/09/2023 08:29, Eli Zaretskii wrote: > > >> What do people think? > > I think we should increase the default size, and the rest (querying > > the system about the pipe size) looks like an unnecessary complication > > to me. > > > > I've added Paul Eggert to this discussion, as I'd like to hear his > > opinions about this stuff. > > Do you think we can get this in before the emacs-30 branch is cut? I'll try to recollect the discussion and review the patches one of these days. Paul, your input (as well as that of everybody else on the CC list) will be most welcome. From debbugs-submit-bounces@debbugs.gnu.org Sun May 26 19:28:36 2024 Received: (at 66020) by debbugs.gnu.org; 26 May 2024 23:28:36 +0000 Received: from localhost ([127.0.0.1]:42737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBNI4-0002ly-AQ for submit@debbugs.gnu.org; Sun, 26 May 2024 19:28:36 -0400 Received: from mail-lj1-f171.google.com ([209.85.208.171]:59782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBNI2-0002lm-In for 66020@debbugs.gnu.org; Sun, 26 May 2024 19:28:35 -0400 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2e724bc466fso93032691fa.3 for <66020@debbugs.gnu.org>; Sun, 26 May 2024 16:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716766040; x=1717370840; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=1F4X5Gb1wLfMOJekEIh10Q4kBJVeuHTsDmjbQfEcKpk=; b=HrNlMuASq47zSDVkjxEdhuXEjxbyeoKjCsQRVM+zAiPuOBstFoK1nBcA7quRSaIDeG XDqsLqzc3cOG9wo3q/vTCAUt6qgdr3gYjaiG+p8MM9o8/cD6OhrYytHNLtm/v7F2YzBn ZRgO/R60pOXuwK2r2CKQFCpHPz+hYP+W84kPP9YwZZ9qHdKV4nCrLnNlYwJBrSg0VX7u k53QuQZO+65DO3qRXgYFSchr9HP6nnwL06iVE1m1rowRNCRYhzfimQtPWjtr6GqpHZm9 c+eR3uq1yQn4y3aaYx1vgGrjYx4kft+TVdur5YCzk9Zmhme91SSYU8hwf6+zMPyk4WhB Hchw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716766040; x=1717370840; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1F4X5Gb1wLfMOJekEIh10Q4kBJVeuHTsDmjbQfEcKpk=; b=plWZ7NTmYjP1yXAokIdk1YJerxRbpRnw7xajSWnXYYZ7ShDlx5GDlWLtA4ZDPVdmiB zfGW+7JIk5OBl3i9Z1O9MeV5cMZolVU/siwxWqdSo9mhkwUkGn+XLo2s3qUUUVCxz6uF yyJLMnuQS17tdLmVyxm5T17fevWlDJB7kla3nrcE/52C5aY4JZsGIN16QR4iHHVW90Ox OpLPK6TgSroLYdNtulH55HnGMFkeu9DufmvN3mYkkfm7AhE3wkkscJGcyBTAtnKBsycD 6SLuA6+sBbZs8Ow4l2UCZ1d/AQ0F6keVPD3/HtCvqoyzXMldu0/P6epbkatgF2S/jxmV meJw== X-Gm-Message-State: AOJu0YxI+Jb5J0t1mSmEbqg6imiK9/ZtUs9ii1oiKe0sq+O2k2hwcRRs Hh/9dgLDQdECGDfqgorP4/I3NgzQgdMG0YtMbS8XuqHQkDd87q+lgVnN5ejJGWV+dnGmZ4/YhJU lcLHOGoxXBmOGlQBJDAr6QBIVLs8= X-Google-Smtp-Source: AGHT+IHLGAuhHqLhw37DlFWRBQqG/8zpUQ2TYSxCMDItyUUTh5ScQ00IJOgn4BUDpAxfkmLvWVDTt3C0NrzHlNYApgc= X-Received: by 2002:a05:651c:88:b0:2e5:5b9f:7732 with SMTP id 38308e7fff4ca-2e95b0c4d16mr68146731fa.26.1716766040105; Sun, 26 May 2024 16:27:20 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 26 May 2024 16:27:19 -0700 From: Stefan Kangas In-Reply-To: <868qzwwoif.fsf@gnu.org> References: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> MIME-Version: 1.0 Date: Sun, 26 May 2024 16:27:19 -0700 Message-ID: Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Eli Zaretskii , eggert@cs.ucla.edu, Dmitry Gutov Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66020 Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I'll try to recollect the discussion and review the patches one of > these days. > > Paul, your input (as well as that of everybody else on the CC list) > will be most welcome. FWIW, I'd be in favor of raising `read-process-output-max' to something like 40960 (as Eli suggested in this thread), or perhaps some power of 2 close to that like 32768 or 65536. This is based on it being seemingly faster in the benchmarks in this thread, and me having used that locally for 2-3 years and noting no adverse effects. See also the discussion here: https://lists.gnu.org/r/emacs-devel/2021-03/msg01461.html (I didn't review patch 1 and 2, so no opinion on those.) From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 08 08:12:13 2024 Received: (at 66020) by debbugs.gnu.org; 8 Jun 2024 12:12:13 +0000 Received: from localhost ([127.0.0.1]:37695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFuvd-0002xO-15 for submit@debbugs.gnu.org; Sat, 08 Jun 2024 08:12:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFuvY-0002x2-V2 for 66020@debbugs.gnu.org; Sat, 08 Jun 2024 08:12:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFuvC-0002ug-W6; Sat, 08 Jun 2024 08:11:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=O7X3A19mnLCX9R8Pg9VOnU2tsbH25kHNg1GeXWYPFNY=; b=PMft6w2rx91z IW+pa3qd9aCG8WrsMpVjQ9a3aBd0ir5Uycu238Ob8uEYKF0PSCMp6vCgBOsPxhgQbISNGohL+ByGV QzptA+5gDqrG/mBH/PcJbPZaFSgtcvEcuOBt4M+BYwjtJ4FE4b3s9q2KqX/bqlnkdKR0jyJnYsyvC OzETjylnXt0WjQ+X2f9ioFk/jsrWUtwJwV4KEt5ITKxWLa4Y2CJ0C+zKwPDfXnFkXMqR8tVje4TI3 HG61SEKqYJ1gHWBeG6864tsS+b+vupbEnco828Cj003bFeHZeLRpGWrKw5+1C9WfSQOUoKfp6x3Se dkO0E1kXgPPGHydRAW/6CQ==; Date: Sat, 08 Jun 2024 15:11:44 +0300 Message-Id: <86o78bd473.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas , dmitry@gutov.dev In-Reply-To: (message from Stefan Kangas on Sun, 26 May 2024 16:27:19 -0700) Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max References: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: eggert@cs.ucla.edu, 66020@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Sun, 26 May 2024 16:27:19 -0700 > Cc: 66020@debbugs.gnu.org, monnier@iro.umontreal.ca > > Eli Zaretskii writes: > > > I'll try to recollect the discussion and review the patches one of > > these days. > > > > Paul, your input (as well as that of everybody else on the CC list) > > will be most welcome. > > FWIW, I'd be in favor of raising `read-process-output-max' to something > like 40960 (as Eli suggested in this thread), or perhaps some power of 2 > close to that like 32768 or 65536. > > This is based on it being seemingly faster in the benchmarks in this > thread, and me having used that locally for 2-3 years and noting no > adverse effects. > > See also the discussion here: > https://lists.gnu.org/r/emacs-devel/2021-03/msg01461.html > > (I didn't review patch 1 and 2, so no opinion on those.) I guess we can install all 3 patches and see if anything breaks. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 08 21:40:21 2024 Received: (at 66020-done) by debbugs.gnu.org; 9 Jun 2024 01:40:21 +0000 Received: from localhost ([127.0.0.1]:54304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sG7Xg-00064o-Cs for submit@debbugs.gnu.org; Sat, 08 Jun 2024 21:40:21 -0400 Received: from wfout8-smtp.messagingengine.com ([64.147.123.151]:36525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sG6JT-0002Uc-D6 for 66020-done@debbugs.gnu.org; Sat, 08 Jun 2024 20:21:36 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id 154881C0007B; Sat, 8 Jun 2024 20:12:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 08 Jun 2024 20:12:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1717891940; x=1717978340; bh=5YdgAUazwrFeEAcxH+jrQHohYJmVLq6K6wgEh339Zbg=; b= HQghM3JD3y583PI0UJL+rebIUoULqaqvBDkj4xwMVwoqB8uCVgbBsJyFr9Rb3DoU A9je4O6cSl7khCrzz9Ei4wOW6GHAFHon8PB0sBcOXr5cZ1bDngLiFQUTnBhJU0Ks tdMnUfcG75bDcg7z7snTLu653JaVVz2bvt2pIYhbN01SBhudSICXJw6zRgp43/bu eKioySt8Pqe5FQsNjZsdlDGrlD3HlkzoWu3oY3GqBZcdFR/Nu1WZB2W4ZOTkT8Lf +oHkwn49KzxQKwwvRCDPj1jQNJDFAFvwgslqwwrygilklDDoFlgAeGFewBk3RqHZ +pnQmxx53+ISP6syiC61aA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1717891940; x= 1717978340; bh=5YdgAUazwrFeEAcxH+jrQHohYJmVLq6K6wgEh339Zbg=; b=E PllIcTZd+khkqNipZ4n9us8I17yWYq8oJwS9FTPvsdmpLNofv79M6V/aVTo2tEE4 dSpBgQ3oqNCUWIS7A26ZdLtBhtilMhe32ex2Ke7/rFrsS7keXz57X/qFFBNM5PCF dZVJtXQKEUJ27MxF6BXnply032aAQlrTQO+CQPKkON4oBNU37rF+e9A9NJlBAR2V tTwxlcD0/m0X0mvnHxekOxZ7agWeA79vxVFRgrrVm9WEDmC4jpejUOytcocUNOPl qFjT9uuKVKNMlEQXYAt7KdcU0VNOj5BFSreQdmm2zt666PFMeELTcs4PZlEoUDwj 1CoW1TiCuVyh0pyI4COkw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedthedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveei uddvnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 8 Jun 2024 20:12:18 -0400 (EDT) Message-ID: <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> Date: Sun, 9 Jun 2024 03:12:16 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Eli Zaretskii , Stefan Kangas References: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86o78bd473.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020-done Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, 66020-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/06/2024 15:11, Eli Zaretskii wrote: >> From: Stefan Kangas >> Date: Sun, 26 May 2024 16:27:19 -0700 >> Cc:66020@debbugs.gnu.org,monnier@iro.umontreal.ca >> >> Eli Zaretskii writes: >> >>> I'll try to recollect the discussion and review the patches one of >>> these days. >>> >>> Paul, your input (as well as that of everybody else on the CC list) >>> will be most welcome. >> FWIW, I'd be in favor of raising `read-process-output-max' to something >> like 40960 (as Eli suggested in this thread), or perhaps some power of 2 >> close to that like 32768 or 65536. >> >> This is based on it being seemingly faster in the benchmarks in this >> thread, and me having used that locally for 2-3 years and noting no >> adverse effects. >> >> See also the discussion here: >> https://lists.gnu.org/r/emacs-devel/2021-03/msg01461.html >> >> (I didn't review patch 1 and 2, so no opinion on those.) > I guess we can install all 3 patches and see if anything breaks. Thank you, now pushed to master. For read-process-output-max, I chose the higher of the powers of two, but please feel free to amend. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 12:01:14 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 16:01:14 +0000 Received: from localhost ([127.0.0.1]:35859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3vu-0000zs-3O for submit@debbugs.gnu.org; Tue, 11 Jun 2024 12:01:14 -0400 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]:58065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3vq-0000zQ-Iy for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 12:01:12 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 3705E13801ED; Mon, 10 Jun 2024 23:12:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 10 Jun 2024 23:12:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1718075546; x=1718161946; bh=JK/GZPOTDL sXCy5cgLMXdq3udLzVSZItgMBX+ZxV8nI=; b=MpqwJRG/FNLG1fvYa6GIkjeAJD 1sKgMeDLcsGYXjehCN6J3/nXaPBwPMyuXQ/l86IEK73xADZdJnPRoFk93tvYxCmS Jr8lBF8k0ehp14nV/vZuI0o5PgAzv967jOVi71AL8mUEtI6IaTrm16VHva78b1GS kuxRI6RLgtrEkSKKPmR9cc+rthEGIDw8WUxouwN9r2FtJiBluBvhwkJsjgEShyMy Yts7ghHKeWuHNbozY8gIi1jtpbb6mmgHaRYgnDQIGJMXZsI6LOmw3xUSP7zRywi4 LprOTZznEwB9F1yDmAern63Y5ov23hbaWFdthaCQkPkmzDA3lF4qFrImaEFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1718075546; x=1718161946; bh=JK/GZPOTDLsXCy5cgLMXdq3udLzV SZItgMBX+ZxV8nI=; b=nhhWSzCyGymqN9QPLcMvXtZLKJ0U3ZKnBXJJ5qhzCnbA Y5iIRdLGgcszVliYnZI2n4GnQOIUfzNctyRbJHcQB3T7+jSLNCoURwWyDpdPx8aj 07n5+SYj5eALGY7n4miYeQhSSKa7m6sAGEmZlyiNKxgp6m1fbke/rrZhsB/1bCM2 LFHuvaC0STb5zg/P3DvvY+epTJJaIEe1bJIZUOCn785CYHLww9tWo8q/Cwa+Of2c teoUpw/An4RkWDzJc+FlcAb5yPsMdKWW2hpppPjuljY8rHr3PCxDYHZDwPY3B0EF yQML5wFARB3RFLVItiqdXUzAv/qmpijyxE9+nbYeiQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduuddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuhffvvehfjgesmhdtreertddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpedtvdeugedvteelvdegvefguedtgfethefggeffkedtkeegveeifeeiudejueff ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jun 2024 23:12:24 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------4d5ZOQY3RYEeg7nAqkyMKYNl" Message-ID: <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> Date: Tue, 11 Jun 2024 06:12:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max From: Dmitry Gutov To: Eli Zaretskii , Stefan Kangas References: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> Content-Language: en-US In-Reply-To: <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020-done Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, 66020-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------4d5ZOQY3RYEeg7nAqkyMKYNl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/06/2024 03:12, Dmitry Gutov wrote: >>> >> I guess we can install all 3 patches and see if anything breaks. > > Thank you, now pushed to master. On the heels of bug#71452, I've pushed three updates. Here's a third one (hopefully last) which I'd like a second opinion on. Process output -- apparently -- needs to be inserted before markers. Is it okay to make adjust_markers_for_insert non-static and call it here? See attached. --------------4d5ZOQY3RYEeg7nAqkyMKYNl Content-Type: text/x-patch; charset=UTF-8; name="read_and_insert_process_output_before_markers.diff" Content-Disposition: attachment; filename="read_and_insert_process_output_before_markers.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9pbnNkZWwuYyBiL3NyYy9pbnNkZWwuYwppbmRleCAzODA5Zjhi YzA2MC4uZmJmNzFlMWU1OTUgMTAwNjQ0Ci0tLSBhL3NyYy9pbnNkZWwuYworKysgYi9zcmMv aW5zZGVsLmMKQEAgLTI4NCw3ICsyODQsNyBAQCBhZGp1c3RfbWFya2Vyc19mb3JfZGVsZXRl IChwdHJkaWZmX3QgZnJvbSwgcHRyZGlmZl90IGZyb21fYnl0ZSwKICAgIHdlIGFkdmFuY2Ug aXQgaWYgZWl0aGVyIGl0cyBpbnNlcnRpb24tdHlwZSBpcyB0CiAgICBvciBCRUZPUkVfTUFS S0VSUyBpcyB0cnVlLiAgKi8KIAotc3RhdGljIHZvaWQKK3ZvaWQKIGFkanVzdF9tYXJrZXJz X2Zvcl9pbnNlcnQgKHB0cmRpZmZfdCBmcm9tLCBwdHJkaWZmX3QgZnJvbV9ieXRlLAogCQkJ ICAgcHRyZGlmZl90IHRvLCBwdHJkaWZmX3QgdG9fYnl0ZSwgYm9vbCBiZWZvcmVfbWFya2Vy cykKIHsKZGlmZiAtLWdpdCBhL3NyYy9saXNwLmggYi9zcmMvbGlzcC5oCmluZGV4IGUxOTEx Y2JiNjYwLi4yMWRhZGE1OTEzMiAxMDA2NDQKLS0tIGEvc3JjL2xpc3AuaAorKysgYi9zcmMv bGlzcC5oCkBAIC00Mzk5LDYgKzQzOTksOCBAQCB2ZXJpZnkgKEZMVF9SQURJWCA9PSAyIHx8 IEZMVF9SQURJWCA9PSAxNik7CiAJCQkJIHB0cmRpZmZfdCwgcHRyZGlmZl90KTsKIGV4dGVy biB2b2lkIGFkanVzdF9tYXJrZXJzX2Zvcl9kZWxldGUgKHB0cmRpZmZfdCwgcHRyZGlmZl90 LAogCQkJCSAgICAgICBwdHJkaWZmX3QsIHB0cmRpZmZfdCk7CitleHRlcm4gdm9pZCBhZGp1 c3RfbWFya2Vyc19mb3JfaW5zZXJ0IChwdHJkaWZmX3QsIHB0cmRpZmZfdCwKKwkJCQkgICAg ICAgcHRyZGlmZl90LCBwdHJkaWZmX3QsIGJvb2wpOwogZXh0ZXJuIHZvaWQgYWRqdXN0X21h cmtlcnNfYnl0ZXBvcyAocHRyZGlmZl90LCBwdHJkaWZmX3QsCiAJCQkJICAgIHB0cmRpZmZf dCwgcHRyZGlmZl90LCBpbnQpOwogZXh0ZXJuIHZvaWQgcmVwbGFjZV9yYW5nZSAocHRyZGlm Zl90LCBwdHJkaWZmX3QsIExpc3BfT2JqZWN0LCBib29sLCBib29sLApkaWZmIC0tZ2l0IGEv c3JjL3Byb2Nlc3MuYyBiL3NyYy9wcm9jZXNzLmMKaW5kZXggYjZlYzExNGUyYjMuLjBiZDNk MDY4NDQxIDEwMDY0NAotLS0gYS9zcmMvcHJvY2Vzcy5jCisrKyBiL3NyYy9wcm9jZXNzLmMK QEAgLTY0MDYsNyArNjQwNiw3IEBAIHJlYWRfYW5kX2luc2VydF9wcm9jZXNzX291dHB1dCAo c3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqYnVmLAogICBpZiAoTklMUCAoQlZBUiAo WEJVRkZFUiAocC0+YnVmZmVyKSwgZW5hYmxlX211bHRpYnl0ZV9jaGFyYWN0ZXJzKSkKIAkg ICAmJiAhIENPRElOR19NQVlfUkVRVUlSRV9ERUNPRElORyAocHJvY2Vzc19jb2RpbmcpKQog ICAgIHsKLSAgICAgIGluc2VydF8xX2JvdGggKGJ1ZiwgbnJlYWQsIG5yZWFkLCAwLCAwLCAw KTsKKyAgICAgIGluc2VydF8xX2JvdGggKGJ1ZiwgbnJlYWQsIG5yZWFkLCAwLCAwLCAxKTsK ICAgICAgIHNpZ25hbF9hZnRlcl9jaGFuZ2UgKFBUIC0gbnJlYWQsIDAsIG5yZWFkKTsKICAg ICB9CiAgIGVsc2UKQEAgLTY0MjMsNiArNjQyMyw5IEBAIHJlYWRfYW5kX2luc2VydF9wcm9j ZXNzX291dHB1dCAoc3RydWN0IExpc3BfUHJvY2VzcyAqcCwgY2hhciAqYnVmLAogICAgICAg c3BlY2JpbmQgKFFpbmhpYml0X21vZGlmaWNhdGlvbl9ob29rcywgUXQpOwogICAgICAgZGVj b2RlX2NvZGluZ19jX3N0cmluZyAocHJvY2Vzc19jb2RpbmcsCiAJCQkgICAgICAodW5zaWdu ZWQgY2hhciAqKSBidWYsIG5yZWFkLCBjdXJidWYpOworICAgICAgYWRqdXN0X21hcmtlcnNf Zm9yX2luc2VydCAoUFQsIFBUX0JZVEUsCisJCQkJIFBUICsgcHJvY2Vzc19jb2RpbmctPnBy b2R1Y2VkX2NoYXIsCisJCQkJIFBUX0JZVEUgKyBwcm9jZXNzX2NvZGluZy0+cHJvZHVjZWQs IHRydWUpOwogICAgICAgdW5iaW5kX3RvIChjb3VudDEsIFFuaWwpOwogCiAgICAgICByZWFk X3Byb2Nlc3Nfb3V0cHV0X3NldF9sYXN0X2NvZGluZ19zeXN0ZW0gKHAsIHByb2Nlc3NfY29k aW5nKTsK --------------4d5ZOQY3RYEeg7nAqkyMKYNl-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 12:01:14 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 16:01:15 +0000 Received: from localhost ([127.0.0.1]:35861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3vu-0000zv-FG for submit@debbugs.gnu.org; Tue, 11 Jun 2024 12:01:14 -0400 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]:50295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3vq-0000zR-J2 for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 12:01:12 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id A3DD0138018F; Tue, 11 Jun 2024 07:41:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 11 Jun 2024 07:41:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1718106070; x=1718192470; bh=bbqZ+JxQB1wwI+YE1Brh6McAYHw/17kKtAfgejnaKSc=; b= JC5+H0C/d9EIXN0vbwklxllDj9Hy9nr13NB7gsR0JWr1yDtCm/QYZkc/YzwLG56p TX7DH09FhJj6nyiY3u+2icQGR5+bBzIbzxJ/zZU5eMjOt09hpL7J4ZOrndQSllBo ZLcaktk/DVuSKoRJgqBOKjtSq+41M75idmSCFxA360fCwHYXydCxGkbnno9EvU5A s51OYbcRleVXbkPrYQ4Bqyg93W+hfAmiWtqgTG1B1h7lLd2QW50VX4ZjA3sAVUqm JfzqA3E35Kcby0BEVWPh0hwwgEC0rQqLoYOddvs3CT3a/FmBbIf9mlbxcoBfPlSk oBEpeQXUFxMm7PtqnM5/eA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718106070; x= 1718192470; bh=bbqZ+JxQB1wwI+YE1Brh6McAYHw/17kKtAfgejnaKSc=; b=l /w40JrKdQMhKsyiJJP1bjRGDEsGMsbu35R9DW3zdTO70iNSxPoslm6qqcZ4c7Seg ANB1Ikevk5gjP6FkCBRznvyK1/SwJyD0gE9KV7/zv85jy9PxbmLo25lmxgIGKcCM psN16JOVoi03qtymnPrA2VDOhCicIoUDO8mBV7SVkfKoMwvBMRYVC4rhZMD0QFXE vDdUi8PVy+5wQQdaPQN99KcEpu25HV/MusJj1gOPRToAn7A54VupjJALy4gpB+IT y+6u5buuW3Fv0q0CR9+7AWefyJuR5PNzt3/KjXQZLvf8FZsO9xIZX1F+CnDydG2I 2Kc9GKgUb/MqeINm/5PAg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduvddggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jun 2024 07:41:08 -0400 (EDT) Message-ID: <7f226168-8782-4b75-b670-5213bebb8223@gutov.dev> Date: Tue, 11 Jun 2024 14:41:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Eli Zaretskii References: <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86frtk6kfs.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020-done Cc: 66020-done@debbugs.gnu.org, eggert@cs.ucla.edu, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 11/06/2024 09:51, Eli Zaretskii wrote: >> Date: Tue, 11 Jun 2024 06:12:21 +0300 >> From: Dmitry Gutov >> Cc:eggert@cs.ucla.edu,monnier@iro.umontreal.ca,66020-done@debbugs.gnu.org >> >> Is it okay to make adjust_markers_for_insert non-static and call it >> here? See attached. > Technically, this is okay, but I'd like to hear from Stefan about > whether it's correct to insert process output before the markers. FWIW, internal-default-process-filter calls insert_from_string_before_markers. My goal is just to maintain compatibility. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 12:33:02 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 16:33:02 +0000 Received: from localhost ([127.0.0.1]:36075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH4Qg-0004pQ-IK for submit@debbugs.gnu.org; Tue, 11 Jun 2024 12:33:02 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH4Qf-0004ow-E5 for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 12:33:02 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C5A304424B4; Tue, 11 Jun 2024 08:55:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1718110554; bh=vDh/+HB7QEBppgFKPR+q5GtMxjo2lGE5YLjRTLLVXfk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ohKzl9BbLaLEelzj23/njsWh6I12b8NC4D51fnNYr3OvkbUCuy3+tKZ635W06ZlUG MgcghzHon/fqQ19eruDNhRj3ZlYmS8LwCDvx9Oi3aFC3wRMUfv3IDFu0IuyjvPdCv3 nzvb+trmrHoM7bMpQPxfG38X1iyXko4+bUl+uTyBa9ydwfhtUvSqc/uCDrciwVf/qL YN5TjNik862Veoiee9CChwfZjC3tkIJOhLx7x/I44lRe6tUDPvVqdE9kqe+u8QDSMv qR268dxE5snUzF5MnNI1p3RP3xTkimIqROHaMjyU50MMJwFS06bOtNYDXHzPV0eJrl 0XreSy+0ch6Jw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9E4FC4420B8; Tue, 11 Jun 2024 08:55:54 -0400 (EDT) Received: from pastel (unknown [24.140.236.196]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 61D9B12032C; Tue, 11 Jun 2024 08:55:54 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max In-Reply-To: <86frtk6kfs.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 11 Jun 2024 09:51:51 +0300") Message-ID: References: <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> Date: Tue, 11 Jun 2024 08:55:53 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.040 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020-done Cc: Dmitry Gutov , eggert@cs.ucla.edu, stefankangas@gmail.com, 66020-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Technically, this is okay, but I'd like to hear from Stefan about > whether it's correct to insert process output before the markers. AFAIK, when the insertion is done by the default process filter, it's indeed done "before the markers". I have no idea why it's done this way and would have preferred it to be different in many cases, but it's been that way forever and changing it would inevitably break some code. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 13:14:21 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 17:14:21 +0000 Received: from localhost ([127.0.0.1]:36210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH54e-00061x-MQ for submit@debbugs.gnu.org; Tue, 11 Jun 2024 13:14:21 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57275) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH54d-00061i-8G for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 13:14:19 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 474AF240101 for <66020-done@debbugs.gnu.org>; Tue, 11 Jun 2024 19:14:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718126054; bh=h0olI15o9U45nUwhJZrag992eTm9YElJETsvYtLQRaY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=V0Y3m6J09fh3+gac6SvWpV/EndaBAaBbwApwUWhKOEb1RkRjde1RjqLC/GtBmHYED t4qQuikGQiwWOfJtj/ZXYEsofnXQcpMgTX/56PsAYMyYZcnh0NMCwsdH/iI7q09BK8 hcp2DAvfxXWX81MiKU6zeG3DkHWR0VTwmSJAQhXz5fmnBgU9jOE4TfQomtsrFumUtZ KGiGoYpZoI7Kn015QFp99GdXlwkHi2TgcBcMFXpNJeDnN8YOmARmG4tsO+tJ9rB6AX WikTdHWcS7znC4Gw3QZdHOQrNwCir4wEOLmxvmXnWGRB7Ne9NJJrzhq0PJVx5CWuG3 /53/RRHfNiHMA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VzFdZ1RV8z6tvn; Tue, 11 Jun 2024 19:14:09 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max In-Reply-To: References: <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> Date: Tue, 11 Jun 2024 17:15:46 +0000 Message-ID: <87ed931jul.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020-done Cc: Dmitry Gutov , Eli Zaretskii , eggert@cs.ucla.edu, stefankangas@gmail.com, 66020-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: >> Technically, this is okay, but I'd like to hear from Stefan about >> whether it's correct to insert process output before the markers. > > AFAIK, when the insertion is done by the default process filter, it's > indeed done "before the markers". I have no idea why it's done this > way and would have preferred it to be different in many cases, but it's > been that way forever and changing it would inevitably break some code. FYI, I just upgraded to the latest master, and observed some lines in *Async-native-compile-log* inserted not at the end, but on the second line before last. Is it something others also see? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 14:09:20 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 18:09:20 +0000 Received: from localhost ([127.0.0.1]:36230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH5vs-0007Pr-2M for submit@debbugs.gnu.org; Tue, 11 Jun 2024 14:09:20 -0400 Received: from wfhigh2-smtp.messagingengine.com ([64.147.123.153]:46835) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH5vp-0007Pe-9e for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 14:09:18 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.west.internal (Postfix) with ESMTP id 963C618000F6; Tue, 11 Jun 2024 14:09:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 11 Jun 2024 14:09:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1718129352; x=1718215752; bh=ToYePKCZObKNWFnmtwFpsmyAiDarZDNAhPlHOBebClo=; b= W6jMsDOq8jyYZmU4Tk4jfJsGJsI9ZF2nD4NQGuKdku5dVTdXSxylRqqPwtJ0+mes iuVKIJq53LsNpQnclNywEvWrXja2e+2EM1UbtOpyYzP5OWRWnLM9Er8j1fVgNfI8 54SBCFwPsaMaV0DzmCzfjF0DF+CQXkIeqUvCxZf5dPbBSU9siwjtbVAEBij7zkJo jI8XvuYXQ/vOnun1WbE8QKzWzO1AjK2ENW4hM2PJ0PYxN2UMf6ubXqhpQsJGMQZu xpT1fnbIWjFQB+2+DdXkjkst/HWOb6aFrJHpHtXx5hW6HOvaebBZiTRtDzmE//Kf R4PwPEeq4duG0/WyfvXCTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718129352; x= 1718215752; bh=ToYePKCZObKNWFnmtwFpsmyAiDarZDNAhPlHOBebClo=; b=a 5GKtd4oohqRj5kYeE7HeW7uiqoS0y9Q3b41ma4IRcRFB/Er6LjGgoEeg73JiDnX9 EKRvUM2jakj3mK6tganwqO5q4izun+VkH3ysYkCxNiDUgeCQcwZOs6S9dvBZihi2 jl1KuefkMEgdHj3Op5772PyVuKmovzPJRJKwFjEsnh+aYAUO0vVB+7PEem0FRVLg XTpkZnjgsfh7R+jsYanG/oi/aOTMEjZmkj68S0MHV+bybNmNjZ0/vPs5lnfaioGK 1zbfpz3lBIQ9VvRJJ/nKTvguWT5omcsTA90sh7r6VcAWcg6U0utJOXWYnV0W937Q 7vQw+UGKLMuVLfY2pz8Wg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduvddguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jun 2024 14:09:08 -0400 (EDT) Message-ID: <0a15da42-9d77-4d1b-bfda-6c3d26ec40ad@gutov.dev> Date: Tue, 11 Jun 2024 21:09:05 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Ihor Radchenko , Stefan Monnier References: <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> <87ed931jul.fsf@localhost> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87ed931jul.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020-done Cc: Eli Zaretskii , eggert@cs.ucla.edu, stefankangas@gmail.com, 66020-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 11/06/2024 20:15, Ihor Radchenko wrote: > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >>> Technically, this is okay, but I'd like to hear from Stefan about >>> whether it's correct to insert process output before the markers. >> AFAIK, when the insertion is done by the default process filter, it's >> indeed done "before the markers". I have no idea why it's done this >> way and would have preferred it to be different in many cases, but it's >> been that way forever and changing it would inevitably break some code. > FYI, I just upgraded to the latest master, and observed some lines in > *Async-native-compile-log* inserted not at the end, but on the second > line before last. > > Is it something others also see? I have now pushed the proposed patch (with "before markers" behavior). Could you rebuild and see whether the async-native-compile scenario improves? From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 15:32:19 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 19:32:19 +0000 Received: from localhost ([127.0.0.1]:36261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7EB-0001Iw-6Y for submit@debbugs.gnu.org; Tue, 11 Jun 2024 15:32:19 -0400 Received: from mout02.posteo.de ([185.67.36.66]:38235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7E9-0001Ig-0c for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 15:32:17 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 160AE240103 for <66020-done@debbugs.gnu.org>; Tue, 11 Jun 2024 21:32:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718134332; bh=K/IKg/y7jFE5GCZhZ3JVOLqDDyRQWfaZ3dXbGCMUFNA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=RfZnMqN9f9dAuICxaN1wJMBKUWZWXC9qxMlO/9XZNZ3PUqYBuAZhnym5uank6QP0U mlcn3rZw277J63lZYXKXo++hfyOv0vYsfhP4/orXnLjw7OEmdyflXQllWUPlQLvdyT 6iYRchWjM5HWnL2fhAuuQPGWC5pSVSbq1exDC+HMrGAUHxJ6H6pwK773kbGZ+RiDVp B+fbP2sy8iHp1XmpH+n+4SLXQJHDCxWHxmho/4j6CZBI4+NP9hqW6WycB3PfMtg+t7 3u6WppaCcTHDqbtxvs77IyuP1YOub3oUj23e3hhd9L5sw9LB8MjZmVk6Wsa4PuGn0T OxnXX8XaNYDfA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VzJhn2f2Bz6tw9; Tue, 11 Jun 2024 21:32:09 +0200 (CEST) From: Ihor Radchenko To: Dmitry Gutov Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max In-Reply-To: <0a15da42-9d77-4d1b-bfda-6c3d26ec40ad@gutov.dev> References: <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> <87ed931jul.fsf@localhost> <0a15da42-9d77-4d1b-bfda-6c3d26ec40ad@gutov.dev> Date: Tue, 11 Jun 2024 19:33:44 +0000 Message-ID: <87le3be0kn.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020-done Cc: 66020-done@debbugs.gnu.org, Eli Zaretskii , eggert@cs.ucla.edu, Stefan Monnier , stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Dmitry Gutov writes: >> FYI, I just upgraded to the latest master, and observed some lines in >> *Async-native-compile-log* inserted not at the end, but on the second >> line before last. >> >> Is it something others also see? > > I have now pushed the proposed patch (with "before markers" behavior). > > Could you rebuild and see whether the async-native-compile scenario > improves? Back to normal now. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 16:00:43 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 20:00:43 +0000 Received: from localhost ([127.0.0.1]:36267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7fe-00022B-SO for submit@debbugs.gnu.org; Tue, 11 Jun 2024 16:00:43 -0400 Received: from wfhigh3-smtp.messagingengine.com ([64.147.123.154]:46277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7fd-00021y-HN for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 16:00:41 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.west.internal (Postfix) with ESMTP id D72C6180012B; Tue, 11 Jun 2024 16:00:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 11 Jun 2024 16:00:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1718136034; x=1718222434; bh=/g2pDHRvcNcq6uSCnVCgj3oWr93FnpLfeCgJ6q0Gf0U=; b= cs2eDw01iR4lUyi+TW8Evp3gGHxbzV2W86BSuGqgrqPR2MZ7W5/SXBAu54Vyekln gqkcTXWCQHFaSzeNGNCUE2m4kEILETSs9JvZEHYHN4JVHrdAWAwknRJbzR9zG4mO J9e5lkO5MRiGEP/SxXHfdx/Sn5Ics0KcResT76ZoZ+fZOXLvkCgI4nhZn3YJlf88 bT6OiP/JoIHObDLlD+QG1SPNBt4DZ+Om401s3Sq6aty8cj069uoNXg/7r+GIWLX1 aHJIOViL3Z/dZfnvN0P3Q81YP4lsN4PuNPeFYgU3ilnSx0xOr3s+QD3UwxXWlwfv cg14+RjomvKmIA3stDciiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718136034; x= 1718222434; bh=/g2pDHRvcNcq6uSCnVCgj3oWr93FnpLfeCgJ6q0Gf0U=; b=V 5t1THqJSdFOZrXZufOeqO8Z/Ogp/fH4c+nqS1L/08wKphddAHME6WD0qmDzHiYGq rIRlFs9WqwfMlLvidaYu+Pfx+Dl806V9bzkmyPG5hw5P1qCku/n50R+giwoAmFr2 cyAMY2DtmTI3CGplsrvg2ce/HKK4+gD23NYam7P/FZObsUZsx49A3QiyOIQbGvdH 6lfNZmUZQBJ6fVKScl1kNXMRR8W1hwevTf+zD0Ife0CSNfyKV8jgXZj/7WpUMXoR jt1XfFW1b9KGX0QFuz7gqkPQbKbeM4RasGJdN2MVr0mJBfQEY1jY5Alt729MRRx8 QyqUICNq2ct7PLvVgN1kA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduvddgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jun 2024 16:00:32 -0400 (EDT) Message-ID: <635a9a9b-8a71-4133-a923-2bec7b12cfbf@gutov.dev> Date: Tue, 11 Jun 2024 23:00:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max To: Ihor Radchenko References: <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> <87ed931jul.fsf@localhost> <0a15da42-9d77-4d1b-bfda-6c3d26ec40ad@gutov.dev> <87le3be0kn.fsf@localhost> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87le3be0kn.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 66020-done Cc: 66020-done@debbugs.gnu.org, Eli Zaretskii , eggert@cs.ucla.edu, Stefan Monnier , stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 11/06/2024 22:33, Ihor Radchenko wrote: >>> FYI, I just upgraded to the latest master, and observed some lines in >>> *Async-native-compile-log* inserted not at the end, but on the second >>> line before last. >>> >>> Is it something others also see? >> I have now pushed the proposed patch (with "before markers" behavior). >> >> Could you rebuild and see whether the async-native-compile scenario >> improves? > Back to normal now. Perfect, thanks for checking. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 16:24:09 2024 Received: (at 66020) by debbugs.gnu.org; 11 Jun 2024 20:24:09 +0000 Received: from localhost ([127.0.0.1]:36361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH82L-0002jC-5b for submit@debbugs.gnu.org; Tue, 11 Jun 2024 16:24:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH82I-0002i3-PV for 66020@debbugs.gnu.org; Tue, 11 Jun 2024 16:24:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sH1CS-0006kC-Lg; Tue, 11 Jun 2024 09:06:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=beimK0F80S4+zr/61uOowweQNzRSqpHqzHabCJAcI5Q=; b=NBDq+Q7EioQA VQbX/NwxG3LeRtSDg7htzZ/CnLFIV2qgidkV3GTmKTGCCqVRQK3gYT6/51OzPGQGVFUP2OPLKYke5 PAODgpv8rOOFhp2Fj9P9jI49+FHQDdKuRIPe6zReByn2XYLloxbBzqj6Dqy52uZapFCbnVJW8f8bK BSjOkwqCOTrvY0Bz4gifXLRnvKfVDSFTROeORg72fbkZfFojkykAwwnrQHCdG06Vy2kfKBCN28JW4 yLf9+yFh20ULlZ0AGqa9BWOYBlnWZZpvwHUxtjFmo/edU6teIbySjgyIaY0A3pwRnEUl0WBqZaJ8r vKerGmfbbGvL1XyCVX0N9g==; Date: Tue, 11 Jun 2024 16:06:05 +0300 Message-Id: <86y17b6342.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Tue, 11 Jun 2024 08:55:53 -0400) Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max References: <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> <86frtk6kfs.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020 Cc: dmitry@gutov.dev, eggert@cs.ucla.edu, stefankangas@gmail.com, 66020@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Dmitry Gutov , stefankangas@gmail.com, > eggert@cs.ucla.edu, 66020-done@debbugs.gnu.org > Date: Tue, 11 Jun 2024 08:55:53 -0400 > > > Technically, this is okay, but I'd like to hear from Stefan about > > whether it's correct to insert process output before the markers. > > AFAIK, when the insertion is done by the default process filter, it's > indeed done "before the markers". I have no idea why it's done this > way and would have preferred it to be different in many cases, but it's > been that way forever and changing it would inevitably break some code. OK, thanks. I guess compatibility wins here. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 11 16:41:40 2024 Received: (at 66020-done) by debbugs.gnu.org; 11 Jun 2024 20:41:40 +0000 Received: from localhost ([127.0.0.1]:36761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH8JH-0006Ii-8V for submit@debbugs.gnu.org; Tue, 11 Jun 2024 16:41:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH82P-0002i3-W1 for 66020-done@debbugs.gnu.org; Tue, 11 Jun 2024 16:24:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGvMH-0001mx-DV; Tue, 11 Jun 2024 02:51:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MMRQqHnyyczCfcyqKXzFr6d4hRNtdS/yS3nr2FXS7pE=; b=MPtFZea/UMyO qjqC6qK5h+eyiCIktONpsaMY5ARlqR36KxVngSEBF4xTA+6PRo2gxDBnl05uUgiRduR1uutJ2TEC7 YHD1eKMCYk4bgP+1gcXIHhgGc1vAcxhAWBA/U25lfLZ5vctuv8jVPqdEuggQTNgU3b2x6n4MACbnh u2B5030thlCH/Dzwk+H2tMdROgmEdXwjUCJny0vSEhOgZmLpfBQURz2ID6cjts347b12I4VcwHw3K m0pT+9pZv8yJ6byhUVQKHjDprqrKXpExOibZ++kBpkK8f3WAfQTCQk2PHs0y3e8yupGyDCJoagir7 Hoqa475s9v6AhDw/weQ7RA==; Date: Tue, 11 Jun 2024 09:51:51 +0300 Message-Id: <86frtk6kfs.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> (message from Dmitry Gutov on Tue, 11 Jun 2024 06:12:21 +0300) Subject: Re: bug#66020: (bug#64735 spin-off): regarding the default for read-process-output-max References: <5c493f86-0af5-256f-41a7-7d886ab4c5e4@gutov.dev> <83ledanvzw.fsf@gnu.org> <83r0n2m7qz.fsf@gnu.org> <26afa109-9ba3-78a3-0e68-7585ae8e3a19@gutov.dev> <83il8dna30.fsf@gnu.org> <83bke5mhvs.fsf@gnu.org> <83a5tmk79p.fsf@gnu.org> <937d9927-506f-aa36-94e9-3cceb8f629dd@gutov.dev> <83zg1hay6q.fsf@gnu.org> <451d6012-e5ab-df6c-50e3-dac20b91781c@gutov.dev> <83led09dlk.fsf@gnu.org> <1d43341a-2e7c-9f1d-68e9-9bac6f4b5fba@gutov.dev> <838r8w3zr2.fsf@gnu.org> <868qzwwoif.fsf@gnu.org> <86o78bd473.fsf@gnu.org> <15f746d0-e635-47a0-a613-2ea31523966a@gutov.dev> <5922967c-1a6e-4b6e-b299-37fb598e5eca@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66020-done Cc: 66020-done@debbugs.gnu.org, eggert@cs.ucla.edu, stefankangas@gmail.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 11 Jun 2024 06:12:21 +0300 > From: Dmitry Gutov > Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, 66020-done@debbugs.gnu.org > > Is it okay to make adjust_markers_for_insert non-static and call it > here? See attached. Technically, this is okay, but I'd like to hear from Stefan about whether it's correct to insert process output before the markers. From unknown Fri Jun 20 07:16:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 10 Jul 2024 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator