From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id 64F0A3858D39 for ; Mon, 15 Nov 2021 16:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 64F0A3858D39 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 1AFGjR7d014828 for ; Tue, 16 Nov 2021 01:45:27 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 1AFGjR7d014828 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1636994727; bh=QO7o+NReD+bY7HySwJ0z+UTi2S2BS2P1NPY5em/2HS8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=gPMEAgoOi33Ytjf8D8URa5iqbufHfqulREBdQWK+as9pix9uUkPrk4PYAfTYpZ8kW 0aLWEww1jIfaJjHr9E3PVbg6juMRAald/rp4hhU6sT+muZJZVZhuSI6ZGJYWtk4OBr f6TRbcloNl5BcJrZvlDVrdxezbnsM2QK+S0CsJWGLTEREBRqP4MIDZKbMWuuNCbm6u HvvOogXRVXIDHlgkXWEUnnwLCM1JzmVQCpzkBk9UGb63OtdMjyzqv3EpTPzkorRWMb Ff6frN+sWXl33vZqY9ERtLGGZA1gJEjuCU3dEz6ba3XVrRCdFEUFrWSSxeq8I4R5t+ 5Z/ckmlI/96YA== X-Nifty-SrcIP: [110.4.221.123] Date: Tue, 16 Nov 2021 01:45:31 +0900 From: Takashi Yano To: cygwin-developers@cygwin.com Subject: Re: cygwin 3.3.x: another problem that may be related to pipes Message-Id: <20211116014531.0c92dc9f4af9156d62c11fcc@nifty.ne.jp> In-Reply-To: <75dcaf48-49d6-a032-9467-145480a3c4a6@cornell.edu> References: <115203324.649908.1636923059546.ref@mail.yahoo.com> <115203324.649908.1636923059546@mail.yahoo.com> <20211115171811.844dce9cce2b4d13262d64f2@nifty.ne.jp> <1f94e84c-59de-bf2c-f244-e4672b981987@cornell.edu> <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp> <20211116001137.7daf62c9f2815d5a92a56df0@nifty.ne.jp> <75dcaf48-49d6-a032-9467-145480a3c4a6@cornell.edu> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 16:45:50 -0000 On Mon, 15 Nov 2021 10:36:19 -0500 Ken Brown wrote: > On 11/15/2021 10:27 AM, Ken Brown wrote: > > On 11/15/2021 10:11 AM, Takashi Yano wrote: > >> I might be wrong. Your code certainly waits for something happening. > >> I am not sure why it works... > > > > FWIW, I got the idea for this from the following code in > > fhandler_socket_unix::listen_pipe: > > > >   io.Status = STATUS_PENDING; > >   if (!is_nonblocking () && !(evt = create_event ())) > >     return -1; > >   status = NtFsControlFile (get_handle (), evt, NULL, NULL, &io, > >                 FSCTL_PIPE_LISTEN, NULL, 0, NULL, 0); > >   if (status == STATUS_PENDING) > >     { > >       waitret = cygwait (evt ?: get_handle (), cw_infinite, > >              cw_cancel | cw_sig_eintr); > >       if (waitret == WAIT_OBJECT_0) > >     status = io.Status; > >     } > > And here's Corinna's answer when I asked her to explain it: > > https://cygwin.com/pipermail/cygwin-developers/2021-April/012093.html I found https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntwritefile says about NtWriteFile(): If the caller opened the file with the DesiredAccess SYNCHRONIZE flag set, the caller can wait for this routine to set the given FileHandle to the signaled state. Also, https://docs.microsoft.com/en-us/windows/win32/devnotes/ntreadfile says about NtReadFile(): If the caller opened the file with the SYNCHRONIZE flag set in DesiredAccess, the calling thread can synchronize to the completion of the read operation by waiting on the file handle, FileHandle. The handle is signaled each time that an I/O operation that was issued on the handle completes. However, the caller must not wait on a handle that was opened for synchronous file access (FILE_SYNCHRONOUS_IO_NONALERT or FILE_SYNCHRONOUS_IO_ALERT). In this case, NtReadFile waits on behalf of the caller and does not return until the read operation is complete. The caller can safely wait on the file handle only if all three of the following conditions are met: * The handle was opened for asynchronous access (that is, neither FILE_SYNCHRONOUS_IO_XXX flag was specified). * The handle is being used for only one I/O operation at a time. * NtReadFile returned STATUS_PENDING. Therefore, in this case, waiting for the pipe handle might be the correct manner. -- Takashi Yano