From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-snd-w04.mail.nifty.com (mta-snd-w04.mail.nifty.com [106.153.227.36]) by sourceware.org (Postfix) with ESMTPS id 8C3D03883014 for ; Fri, 28 Jun 2024 12:17:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C3D03883014 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nifty.ne.jp ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8C3D03883014 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=106.153.227.36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719577061; cv=none; b=Nk+gJMrmiBSYzEuC1NvJbsWObFbk+uZPb8+d3/dZB/TcnVwfvVQohVP+fqSNu8C7cAZ5M//gTpEwT2DpqZgWE7syrkyPtL3/bMgrUX6rPrOaJD00/qPobACXJ1pJl6pc9Q9mXHE6QxyyXRwUlnmuHkSNRpMDEOpEbNSIUaoRmzI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719577061; c=relaxed/simple; bh=/9R1YfMGtHx/XJhA9DsGT/c9jz1ZFiNIoqodeJ9HUX8=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=qRUhFxH/Y/epkkXYjsEqL0Z3xYUG8ApwdjupjGcGrYzmcqsMwlw5l16TxQKK8jt/xkK9Wm55M7enhuVSUZDcRf0OTmu5KZpqpV+xlVKpJbVqz4+g1ds1hhXFkcmZlNggt++2gdhavy4VDmIF/Rh5nf16jaDCgiz9Fs3HhCvmpAk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from HP-Z230 by mta-snd-w04.mail.nifty.com with ESMTP id <20240628121727979.LOYV.6907.HP-Z230@nifty.com>; Fri, 28 Jun 2024 21:17:27 +0900 Date: Fri, 28 Jun 2024 21:17:26 +0900 From: Takashi Yano To: cygwin@cygwin.com Cc: Johannes Khoshnazar-Thoma Subject: Re: cygwin application hangs on closing console Message-Id: <20240628211726.c131e0a300046d1fa46f6b53@nifty.ne.jp> In-Reply-To: <95442cfe-a87c-4816-b337-b130e481e3f1@johannesthoma.com> References: <20240423035104.85352f8a8d821c0f4d569d18@nifty.ne.jp> <20240423192606.7b4aa04685afca2525eb5ed3@nifty.ne.jp> <6dd8a568-88c0-42d5-aa46-b09247cdecec@johannesthoma.com> <5ed3b0b8-d4f8-454c-951a-fc7b85a7c302@johannesthoma.com> <95442cfe-a87c-4816-b337-b130e481e3f1@johannesthoma.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=default-1th84yt82rvi; t=1719577048; bh=taQbBMb10U4JP1ukCsAL/Spd2EWrsLoFmmIYf8EvTX0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=X+6mndVKMk0XgJGuJOyQe6yvHZLvPUIqjLFiqH1GeuJuHse58uLqOkhujhUVzExjm28sBP++ RB/rl1AnGIERPVF8dGaqs2J9MyfLZpFXnyl0P4nNo3qv035HM24rAxFcmSglLlbZbK+I13SKyx wH4S3k4QqVqBK7gNisqgGf9UgeMCw1IZAOtdGhgBYNY8zUNKltIcUauZ/apGdu6ebE22Z+6n3h t8RDqKWtDcPUZ+/jHa9ieLb+pqgi6xRj7QnZx3vDtoUprX7O4f9rxUbpmPp88fICTGvFjGgEMI EOq7n8iY0F8n/IBAQDAJ9ekXyH/J6nTdud0x6Yr9+ulknBPQ== X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,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 List-Id: Sorry for very late replay. On Mon, 3 Jun 2024 15:20:32 +0200 Johannes Khoshnazar-Thoma wrote: > We did more testing and it looks like the name of the event > that signals console master thread start and end is shared between > unrelated processes (it uses the console minor which is always (?) > 0 when running from a powershell). > > So since it is a two-state event (as opposed to a semaphore) > in theory the following can happen: > > Process A Process B > SetEvent(e) > SetEvent(e) > Waitforevent(e) > Waitforevent(e) This should not happen. Master thread is unique to console. get_minor() number is always 0 for the first opened console. If you open another powershell window and start cygwin process while the first cygwin process is still active, the get_minor() returns 1. Waiting for thread_sync_event is executed only if (shared_console_info[unit] && con.owner == myself->pid) con.owner is in the shared memory which is shared among all processes started in the same console. Therefore, only the one process start to wait the event. > The second SetEvent does nothing. As a result the > later Waitforevent is stuck (which is what we observe). > > So the question is: why should this event be used in > unrelated cygwin processes? Is there a technical reason > we don't understand (yet) for doing that (sharing the event). > > We patched cygwin to use pseudo random event names (the > tm_usec field of gettimeofday()) and the stuckness vanished. > So unless there is a reason for sharing the event between > cygwin processes this patch should work: Do you really confirm that your patch resolves the issue? If so, the cause might be some kind of race issue. -- Takashi Yano