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 3EBB8385800F for ; Thu, 3 Dec 2020 06:57:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3EBB8385800F 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 0B36vXgj090996 for ; Wed, 2 Dec 2020 22:57:33 -0800 (PST) (envelope-from mark@maxrnd.com) X-Authentication-Warning: m0.truegem.net: mark owned process doing -bs Date: Wed, 2 Dec 2020 22:57:33 -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: 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 06:57:37 -0000 [replying to myself.. sorry..] On Wed, 2 Dec 2020, Mark Geisert wrote: > 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 Putting the workaround in fhandler_socket_local::socket() compiles fine and the OP's Python testing issue seems fixed. OTOH XWin and X apps exit soon after starting so that's no bueno. It looks like the individual Python tests that exhibit the problem are going to need patching. Does that sound about right? Thanks again, ..mark