DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 4AJ9MQeT3045980 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 4AJ9MQeT3045980 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=dnM5JMh4 X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C55B3858D21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1732008146; bh=ChVEx2hgchHeLjeSyZcyWkZKYAKQ2VXxxyOer8ko6AI=; 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=dnM5JMh4uHnsWB01EOMJbr4VqAQLQjmnOq8wQyJVnuSWIW5ecNLLs8zjCIMprDgbH tNgqxJWWWBSOhwfTwb2h3pCAhcXK+D7/UFxDd88JNQOhgfvv3mNYipYHEDjeM4IEoa UV4fvlpq8nd9BvhUcW89c7yAyzJBDPC7mOT6VyaU= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8A773858D21 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A8A773858D21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732008115; cv=none; b=NzRgngFZC288h06962IXstt83IkTRGcitC7m8Hri9v1OqIGJ9rl4cnoWXsPXykfTEp/9n2inJ1Kl0ui/aGXnKkpFabvPHGEedZz0CPhsvocGt+/v3TTEnclV0qOhP3SfC2fbwsLIzRl4XDcTT7Q/aO5npNt1kl2H8g2pZzlxK+c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732008115; c=relaxed/simple; bh=aVwHPW1ZGxu/pQa45PIzLdCph4eLWOSTiUywVg6H96I=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=DL2loy+bAjegujL/14A12LF204A1bQUgx6vrjx7BnfBvtCbKVo3hq4vYII1f6Xu6yqKMEkMhXiQZ+A/p7mhnB7dF4ZMdSUKubRnuBbsDOkFv+vo4GQUYahPfetwdZBLv1pcMq6LfcQH9+Jb1XuA1jdLKQPFZMOEV7TxGIq5BMZs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A8A773858D21 Date: Tue, 19 Nov 2024 18:21:52 +0900 To: cygwin AT cygwin DOT com Subject: Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals Message-Id: <20241119182152.c2195f50ed7091fbed644606@nifty.ne.jp> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 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" On Tue, 12 Nov 2024 10:53:58 +0100 Christian Franke wrote: > Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD: > > Testcase (attached): > > $ gcc -O2 -o manysignals manysignals.c > > $ ./manysignals > fork() = 1833 > ... > fork() = 1848 > ... > kill(1833, 17) > ... > kill(1848, 17) > kill(1833, 9) > ... > kill(1848, 9) > waitpid(1833, ., 0) > > > Run this in second terminal: > > $ watch "ps | sed -n '1p;/manysignals/{/sed/d;p}'" > > If 'S' appear in the first column, the child processes likely reached > the final SIGSTOP state. This takes some time. The parent process may > still hang in first waitpid() but should not. > > If the parent process is aborted with ^C, child processes may be stopped > or left behind. Occasionally a child process that can not be stopped by > Cygwin (kill -9) is left behind. > > Tested with ancient (i7-2600K) and more recent (i7-14700K) CPU :-) > > > Unrelated to the above, but related to 'stress-ng --cpu-sched' which > uses sched_get/setscheduler(): > > - sched_getscheduler() always returns SCHED_FIFO. As far as I understand > Linux sched(7), this is a non-preemptive real-time policy. The > preemptive SCHED_RR would possibly a more reasonable value. > Unfortunately SCHED_OTHER cannot be used because it would require to > ignore the priority. > > - sched_setscheduler() always fails with ENOSYS. It IMO should allow to > set 'param->sched_priority' if 'policy' is equal to the value returned > by sched_getscheduler(). Thanks for the report and the test case. I'm now looking into the issue. Please wait a while. -- 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