DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 46PG3eVS4080302 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=ndRpFWPa X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FF7F3858430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1721923418; bh=fBFZxUaK0Ugls6wuI0FuRv0IAv4Hre4/L4e+PrRAfj8=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ndRpFWPaYf9RVI7YiWzWX52Xw5I0Yts6CUQ34k78cTbZmH9DoBfswT6XwAXiV/AbB k/bAkQS8TQE6eDQQyD/vEnSTV3k9whvddb715yAh93WTd0yB8x3KVz9t1GiK5X+g4l ARmU6cSa7bo3MJ7yX+KgRSMNsmIh0A0I4LYel4T0= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 765F73858D35 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 765F73858D35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721923361; cv=none; b=jh8Gk3kz/ia1VodKMSjaOEz+RZ+spxFa1HlXfxNTf0rAvDmVRnEnCBviBJ8Jk1GxXvNbaH2RSRlpsyttDhrM/kiFpr84S1UPArDaXmfqqFTcu12Oh6renG39AA8uz+65h1CFJYQLvTbw1Y9GEhrpaZ08aguXKpZCpA148NcvVBs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721923361; c=relaxed/simple; bh=oJP4IYw4rRs/B0VtxW/T9vUrp+epnlpp1+L+kwdMSZ8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=pNhjlvQLDdBk7gn5PZKl+67AWusSNbYiIrvDErI1p9foUNMyXSkSBb5PiJEWI0v5bOFhQOwcM6sIy1O8FEk0HdD5mTOi4tFoWs3C1GEV2DUJWFCsXtyI4jFXBBh0iJQ6oJxZ7DK/dyqDxQVw/SvGm8lPEautDwGcJ+wT7fnMQ3A= ARC-Authentication-Results: i=1; server2.sourceware.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721923358; x=1722528158; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oJP4IYw4rRs/B0VtxW/T9vUrp+epnlpp1+L+kwdMSZ8=; b=PXQFRKKSX7KHZfnaN5wvMSBtM6i8LCo6nqxLLJ4VzcokWXecdZqjKUzNLisRDodhRi u2d4dj+SHM+9fu44bUVpa3R0V5cZw9ik8MDOIkQxyez39VNp0Lfd/kkgyHFeDHLELB0z YGj6FNdz9WcRGiFUscPhGk30Hh75BSuNlubMUzm9nWt8gfU4KszGpBmwUVYMxMrBRpwT /bsBxBQYiO9hQPNU/OeUNRiyQf23OvNdo58pvODk7Mla8ThdZaH9iQ0SDTafcaxZ1HSI AjObN3god3yiCBGxLqYGiQjHRvXtcZ+pKp398iZ1ru9FWPTtDEYncunk24U+s7cdgarB kvkQ== X-Gm-Message-State: AOJu0Yyjz5TmH9O0I8MNlwh3gpmudXUoy0EqyGFWXfA3WqAz/et+1vSC xg5ROjLLyU1batgWyAIL1OwC/wyyy1lNGTs3xHnSA5B9U7Qwqdxro6REjjXq+Z/oZ/KAO6uTzuU PZZp8Yfw0EPE2yYOhgwHo8pWqCgT3MHBI X-Google-Smtp-Source: AGHT+IE0TNe8HsxJ/noPVsSc5Fm+ExWtZmWifo+wgp+kAge/3HP4m83UDw670Uo6EX5r9Sr2kXVL6rvkDG8aRDdTAPY= X-Received: by 2002:a17:90b:3844:b0:2c9:a3d4:f044 with SMTP id 98e67ed59e1d1-2cf237b7546mr3343493a91.11.1721923357954; Thu, 25 Jul 2024 09:02:37 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 25 Jul 2024 12:02:21 -0400 Message-ID: Subject: RE: Rewriting the FIFO code To: cygwin AT cygwin DOT com X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Jameson Nash via Cygwin Reply-To: Jameson Nash Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Cygwin" I am hopping in late to this conversation, after working on debugging a confusing issue where my NamedPipe stopped working reliably after being passed to a cygwin program, where I believe it used to work okay with older versions of cygwin. I just want to point out that the current flag being used (Win32 calls it PIPE_NOWAIT) is documented as do-not-use (e.g. https://devblogs.microsoft.com/oldnewthing/20110114-00/?p=11753) as it interferes with the reliable execution of other programs that are using the same pipe end, and that do not want to use the inefficient busy-wait polling that cygwin's implementation does. As the documentation points out, there is no way to recover correct behavior of OVERLAPPED while the flag is enabled. By contrast, however, with PIPE_WAIT mode, it is possible to implement non-blocking IO, including select, with OVERLAPPED operations, by using ReadFile (with a size of 0) followed by PeekNamedPipe (if you want to estimate the number of bytes to read) followed by a ReadFile of that number of bytes (or an estimated number) followed by an immediate CancelIOEx (or CancelIO on older platforms). I can post some example code from libuv if that would be helpful? Removing this `PIPE_WAIT` change would eventually also allow fixing the implementation of `select` in cygwin to actually use event-driven notifications instead of emulating them with a slow loop as is done now (https://cygwin.com/cygwin-ug-net/highlights.html). Thanks! -jameson post note: I also wrote up some of this in https://github.com/libuv/libuv/issues/4467 so that google hopefully indexes it in case anyone manages to run across the same problem in nodejs and searches for related issues, but I only wrote a few details there of how libuv might be impacted by this, without the specifics of how cygwin could be fixed -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple