From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 291671F54E for ; Thu, 11 Aug 2022 08:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234356AbiHKIrd (ORCPT ); Thu, 11 Aug 2022 04:47:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233856AbiHKIrb (ORCPT ); Thu, 11 Aug 2022 04:47:31 -0400 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05C49910B6 for ; Thu, 11 Aug 2022 01:47:30 -0700 (PDT) Received: (qmail 8614 invoked by uid 109); 11 Aug 2022 08:47:30 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 11 Aug 2022 08:47:30 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 19923 invoked by uid 111); 11 Aug 2022 08:47:30 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 11 Aug 2022 04:47:30 -0400 Authentication-Results: peff.net; auth=none Date: Thu, 11 Aug 2022 04:47:29 -0400 From: Jeff King To: =?utf-8?B?UmVuw6k=?= Scharfe Cc: Junio C Hamano , git@vger.kernel.org, Johannes Schindelin Subject: Re: [PATCH] mingw: handle writes to non-blocking pipe Message-ID: References: <41477326-5493-4d3c-246d-8a28969fa73e@web.de> <6854c54c-12ff-f613-4cdc-18b3b1a55ef1@web.de> <72d007c5-9429-1612-24d7-af5db906dd63@web.de> <77244ffe-41c1-65bd-8984-8ed6909ffe07@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77244ffe-41c1-65bd-8984-8ed6909ffe07@web.de> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Aug 11, 2022 at 12:34:46AM +0200, René Scharfe wrote: > > OK, so we call GetNamedPipeInfo() to find the size of the pipe buffer. > > It's unclear to me from Microsoft's docs if that is the _total_ size, or > > if it's the remaining available size. Hopefully the latter, since none > > of this works otherwise. ;) > > > > But two corner cases: > > > > - If we fail to get the size, we guess that it's the maximum. Is this > > dangerous? I'm not sure why the call would fail, but if for some > > reason it did fail and we can't make forward progress, would we > > enter an infinite recursion of mingw_write()? Would it be safer to > > bail with EAGAIN in such a case (through granted, that probably just > > puts us into an infinite loop in xwrite())? > > AFAIU it's the total size, not the available space. I think I confused > it with PIPE_BUF, which we should use instead. Hmm. If it's giving us the total size, that seems like it may fail in a case like this: - we write a smaller amount to the pipe, say 7168 bytes. That leaves 1024 bytes in the buffer. The reader reads nothing yet. - now we try to write another 4096 bytes. That's too big, so we get ENOSPC. But when we ask for the pipe size, it tells us 8192. So we _don't_ try to do a partial write of the remaining size, and return EAGAIN. But now we've made no forward progress (i.e., even though poll() said we could write, we don't, and we end up in the xwrite loop). So we really do want to try to get a partial write. Even a single byte means we are making forward progress. > Alternatively we could retry with ever smaller sizes, down to one byte, > to avoid EAGAIN as much as possible. Sounds costly, though. It's definitely not optimal, but it may not be too bad. If we cut the size in half each time, then at worst we make log2(N) extra write attempts, and we end up with a partial write within 50% of the optimal size. -Peff