X-Recipient: archive-cygwin AT delorie DOT com X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CD00D385141E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huarp.harvard.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=allen AT huarp DOT harvard DOT edu Subject: Re: Unix Domain Socket Limitation? To: Ken Brown , cygwin References: <71490665-31b0-f63c-74da-461a053fac21 AT huarp DOT harvard DOT edu> <55ea1649-1979-6238-75ab-69100c22e069 AT cornell DOT edu> <4260ad1b-4ab2-fa36-fd0e-7c9644560114 AT huarp DOT harvard DOT edu> <38a82f82-1ef9-768e-7d3e-15f63147e188 AT cornell DOT edu> <16165727-f614-1543-70bc-36457ddbf260 AT cornell DOT edu> From: Norton Allen Message-ID: <75d1315b-5a56-a2e5-310d-6ac33a3cf17c@huarp.harvard.edu> Date: Mon, 30 Nov 2020 13:26:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <16165727-f614-1543-70bc-36457ddbf260@cornell.edu> Content-Language: en-US X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 0AUIRM4j013694 On 11/30/2020 1:14 PM, Ken Brown wrote: > I can reproduce the hang, and it happens if I use the new AF_UNIX code > also. But what I'm seeing (at least with the new code) isn't exactly > what you describe. > > When the server's first select call returns, accept succeeds.  The > server then calls select a second time, and that call doesn't return.  > I haven't checked yet to see what's going on in the client, and I may > not get to that for a while. > That's good news, and seems to be consistent with my theory that it is some sort of race condition that might be particularly sensitive to system-specific timing. I am compiling cygwin1.dll now. -- 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