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:	<d268ca90-3c5b-4de6-9dd5-320ee713283c AT johannesthoma DOT com>
	<20240423035104 DOT 85352f8a8d821c0f4d569d18 AT nifty DOT ne DOT jp>
	<b71816f0-633c-4eaf-b9d6-955b10e4866a AT johannesthoma DOT com>
	<20240423192606 DOT 7b4aa04685afca2525eb5ed3 AT nifty DOT ne DOT jp>
	<6dd8a568-88c0-42d5-aa46-b09247cdecec AT johannesthoma DOT com>
	<b67fc4f5-3fbb-454a-a0ce-da4f987924dc AT johannesthoma DOT com>
	<d00f900a-e70c-4a2b-9570-0d3c9fcd45d2 AT SystematicSW DOT ab DOT ca>
	<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
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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 <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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

- Raw text -