From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 83D803858013 for ; Thu, 3 Dec 2020 02:09:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 83D803858013 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: from localhost (mark@localhost) by m0.truegem.net (8.12.11/8.12.11) with ESMTP id 0B329NKb008245 for ; Wed, 2 Dec 2020 18:09:23 -0800 (PST) (envelope-from mark@maxrnd.com) X-Authentication-Warning: m0.truegem.net: mark owned process doing -bs Date: Wed, 2 Dec 2020 18:09:23 -0800 (PST) From: Mark Geisert X-X-Sender: mark@m0.truegem.net To: cygwin-developers@cygwin.com Subject: Re: python fails asyncio tests (py 3.7 & 3.8) In-Reply-To: <20201202133813.GP303847@calimero.vinschen.de> Message-ID: References: <9976c726-8bfd-febe-ac86-f7cbf3cc958b@maxrnd.com> <20201202133813.GP303847@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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-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: Thu, 03 Dec 2020 02:09:27 -0000 Hi Corinna, On Wed, 2 Dec 2020, Corinna Vinschen wrote: [...] > > This is apparently an old problem in the still current AF_LOCAL > implementation. Christian Franke encountered it when porting postfix: > > https://sourceware.org/legacy-ml/cygwin/2014-08/msg00420.html > > The problem is the security handshake between listening/accepting socket > and connecting socket. The connecting socket send its half of the > handshake and waits for accept on the other side to return the other > half. However, if the listening side doesn't accept right away, the > connecting side hangs. > > The workaround right now is to call > > int peercred_off = 1; > fd = socket (AF_LOCAL, SOCK_STREAM, 0); > setsockopt(fd, SOL_SOCKET, SO_PEERCRED, &peercred_off, sizeof peercred_off); > > This disables the security handshake. I see. For this problem report should the setsockopt() workaround be applied to Python (yikes!) or can it be done for all apps at once in fhandler_socket_local::socket()? I might be able to look into the standing issue with the security handshake later on, if (my) time permits. I appreciate the history/explanation on this. Thanks & Regards, ..mark