DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 45SCIpA23680164 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=gVDfnNcu X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D104382DB3E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1719577129; bh=9uDa39rS0gjFYkFcTpZWqpr9VXnkqOCOtDF/s+mp7oQ=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=gVDfnNcuBh6cxspJyJ88TAcqDcyhsG2ft61LBKN6ezU/OTODyUNLi0T4zQ4ccPA0f SvgfxgP3Gk7muJ4vKPcNZDthIB9d55xkfWcAUrhpMn43c9+pxNpPOkIWbkE86tXJ4y 6FFMcQM/tV4mSw3ZIEFghoiTnqlVEY+W5j/6BOjw= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C3D03883014 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8C3D03883014 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 Date: Fri, 28 Jun 2024 21:17:26 +0900 To: cygwin AT cygwin DOT com 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 DOT 85352f8a8d821c0f4d569d18 AT nifty DOT ne DOT jp> <20240423192606 DOT 7b4aa04685afca2525eb5ed3 AT nifty DOT ne DOT jp> <6dd8a568-88c0-42d5-aa46-b09247cdecec AT johannesthoma DOT com> <5ed3b0b8-d4f8-454c-951a-fc7b85a7c302 AT johannesthoma DOT com> <95442cfe-a87c-4816-b337-b130e481e3f1 AT johannesthoma DOT com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 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 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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 -- 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