DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 46QLPIwn543930 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=xAyTfD2F X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C1783860740 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1722029116; bh=bJPKkS5IvM1epqk04SXo9qK2Exu+5SsH5Da0Mq4cH7Q=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=xAyTfD2Ftv1LvJCjg2eqAKE3tNDhtEpQWr490+uVsYMKLjh95rtaZel56BNiBJXGB iGmI3Ycn67NQaLHubVQZBREtiLNyZ/PuvddBZ5uIJmxyr98F2NcFGbs4Gwa3Kz/YFo 55qv8N/0XexvZvVDBuzmNXo1+yK0io1wMH4ClD9M= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 037993858C66 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 037993858C66 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722029061; cv=none; b=B0dMZKdVVnrLOJiQezTZO3o/ZQZN4nqVCYcT9pNAKIqzfMw2xcPCgBscmbIBtcDt6MMNONugtJonNPWZ+ZkxodZzjYhbpqmiooRRHeN33UZI/aKiW1uWq+q0Qi1Y5DSw2CsEa9tEt+64QZGNgjlGEUy20UtV9dCSwWWSKO9HuuE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722029061; c=relaxed/simple; bh=IBjVUteWHAHNhwOuAVR/kGlzX8BOBNb12XjL9aL858k=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=tIn7PMqnFPbzFXUrlsJffytqVjrPuMB5zoytKELXAkCHogLKg3FAaWKEFBkheO7A03X9SrLCgkbfYFMw0P/WdAXGMlWwNab98ZwHZsSW7zRydpmKcfOwhd4p73Kjs332V8uNY1tEbccAc6rGVmt9hKV7JZafGhCjQYPjDzcxKqk= 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=1722029057; x=1722633857; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IBjVUteWHAHNhwOuAVR/kGlzX8BOBNb12XjL9aL858k=; b=wp1kSE6t5hIRtU2d8rB9nGzJ1n7rc392ASAoqDaxvFcDJgu+xYilckFmaINnqurfT8 JgAYU7WHNtIzhgcdoiUVwYul3cu2q8VyFtZC/Et78v0t2aSgC3LyfsmVjhrcHQS7pDgP kHApwuaUKPcV4fKO26+25Hi7WnMG8onLyhx2MVDJ6c37COU9ngvNGXnmRZXSO3VWXy9G s0PhtW87DiucDDjUpvSK+g5CNfL9Om/zYWSUL9iHo7PQLTQoI+uuZHFJY0v/tFck7tmX WEL6kSOML3BuN4Xmx5pFGKrsBoTVQr18GQiMbksw5SM4hk1S7ivo5vSBgyfzBO2teh9H kHXw== X-Gm-Message-State: AOJu0YxRtq//FN3Bu7/OKkShhbH6DBJimkx4rtJl3Xqw74xs289s1hqB eWAFa8Tx35UYXmHvQBNw9D19Servspm1zt0sKFfTG08GopTLK/25NihrsmjUIZwif1Bcq34h4/M NbToSEdcOiQsw2N5RB8lyilzYxZ95JA== X-Google-Smtp-Source: AGHT+IF5+Bgv0ZVhp8IQgJkBo+wR2q80iD91YF3mJtchyGLfuWZsY0zQE3Ij19/8EtcV+2swLIx8UJwUZvrJRT8cVno= X-Received: by 2002:a05:6a20:8403:b0:1c4:2132:e205 with SMTP id adf61e73a8af0-1c4a14df556mr774026637.48.1722029057168; Fri, 26 Jul 2024 14:24:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 26 Jul 2024 17:24:01 -0400 Message-ID: Subject: Re: Rewriting the FIFO code To: cygwin AT cygwin DOT com X-Spam-Status: No, score=-1.9 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 for readable instead of emulating it with a slow poll 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 second post note: sorry if this is a duplicate email, but I tried to send it yesterday and forgot to enable plain text mode so it was first sent as html and didn't seem to have gotten through to the list -- 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