X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	q=dns; s=default; b=tmMBNBjnwQpyq5iVrqtjyOaLg5UbsBu2WTv2jVENCCi
	1NRaXY6o22/CBKc9A5uM6Em8V5vgIf4g/Y8MHWuuA1Hs86h3b6IIfzz004gA58nc
	KQX/g1nip05yHgh9Y3viHvvHfZ+PIMcMdDE1V7DKoSk1m5tUEHl6UkEUtkHFvrmY
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-type:content-transfer-encoding;
	s=default; bh=jv5GJQeNK0rSvV0W45wnjhmuMos=; b=jS5opWD3IPOp7tSyO
	XD/R0XlQAxpO8TvLcB0l4mW2yzInLt2Mh052K8V5asfX++VQclhn0kirbyw+1j6d
	KCzfCnvC531fyZW+ZOWkob3aw3mzQBg35Mil1imjHgsDPwHjx0/IuFP5nUDV4wRZ
	aO/drnKiTTr4o8lDyLyd7xyRfU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-6.4 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=ideally, HDKIM-Filter:v2.10.3, HX-Spam-Relays-External:Sendmail, H*RU:Sendmail
X-HELO:	conssluserg-04.nifty.com
DKIM-Filter:	OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com x7HGhCeH026092
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1566060192; bh=MRhEzTF81/sAysH/y4LaKYX7xJSdL6zFXAkCAfvx+3g=; h=Date:From:To:Subject:In-Reply-To:References:From; b=dvLkGA18uE1I4QuDTjqc/kQ8CoKE/Q8oZPl2SzCv2Rw6lAAx4327Itb4okotFReuK E59/hlLrmFi/fFgD5gBpxnXi93JjWshp+fxfgDJcAaql3b6XE3FMzZfWvAowcVnde+ PHcgON9uZmnS0GOyuDKjAJOsOp0mE9HAspA+V5ktTsOV1v1R4cnnL3q+a1+JZPCHDc +lLBbIr8L8ZM/7lwEk/uPA1SsGBj8vNOlKyQbPJJAzS9CxoJDJNx5E5T4nQawMOywc 4PoY6y24agU432clkS41Ou7RKR8TuRm9bE4+3Jm1MXWhn9MGp5cnzOA1eXjTVL3tfJ L3Antpy2/LUCQ==
Date:	Sun, 18 Aug 2019 01:43:17 +0900
From:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Message-Id:	<20190818014317.38e23198147dad936da1ac94@nifty.ne.jp>
In-Reply-To:	<20190816144811.GW11632@calimero.vinschen.de>
References:	<20190812153613 DOT GN11632 AT calimero DOT vinschen DOT de> <20190813104753 DOT GU11632 AT calimero DOT vinschen DOT de> <20190814204100 DOT 659fe40d928eae15338198a7 AT nifty DOT ne DOT jp> <20190814204717 DOT caf6884b1216bbeee2f586d6 AT nifty DOT ne DOT jp> <20190814134900 DOT GY11632 AT calimero DOT vinschen DOT de> <20190815042126 DOT 7c2f0baf57b4a82f7d013f74 AT nifty DOT ne DOT jp> <20190815074930 DOT GF11632 AT calimero DOT vinschen DOT de> <20190815103638 DOT GO11632 AT calimero DOT vinschen DOT de> <20190815150436 DOT GP11632 AT calimero DOT vinschen DOT de> <20190815150908 DOT GQ11632 AT calimero DOT vinschen DOT de> <20190816144811 DOT GW11632 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
X-IsSubscribed:	yes

Hi Corinna,

On Fri, 16 Aug 2019 16:48:11 +0200
Corinna Vinschen wrote:
> I now had an idea, but I'm not entirely sure if it's the right thing to
> do.  Can you please test this?  It consists of two patches, one with the
> revamped signalfd handling, and one with the revert of the signalfd
> patch I applied a couple of days ago.
> 
> Quick description: I dropped signalfd_select_wait entirely.  Instead,
> wait_sig sets or resets a manual event object to indicate if there are
> signals pending in the queue, even after trying to handle them the
> normal way.  That usually means they are blocked.
> 
> select() uses the event to wake up from WFMO, if at least one signalfd
> is present in the read descriptor set.  The rest is done via the peek
> and verify functions in select, which basically just check if this
> signalfd is waiting for one of the pending signals.
> 
> The reversion of my patch from a couple days ago is not required as
> such, but after thinking about this a while I'm convinced that this was
> just me not getting the full picture.  Also, reverting this patch would
> revert to seeing a SEGV in your testcase and thus a bug in the new code,
> too.
> 
> I attached both patches.  It would be pretty nice if you could test them
> and point out any problems you get with this new code.
> 
> Please note that you should ideally perform a full rebuild due to the
> slight change in TLS layout.

I confirmed that my STC and script command works as expected with these
patches.

Thank you for greate work!

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -