From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtprelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by sourceware.org (Postfix) with ESMTPS id 8ED993858D37 for ; Mon, 6 Jul 2020 13:16:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8ED993858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=beniston.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon@beniston.com Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 09FC6181D341E for ; Mon, 6 Jul 2020 13:16:07 +0000 (UTC) X-Session-Marker: 6A6F6E4062656E6973746F6E2E636F6D X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, jon@beniston.com, , RULES_HIT:10:41:355:379:541:542:599:988:989:1155:1260:1277:1311:1313:1314:1345:1381:1437:1515:1516:1518:1534:1540:1587:1593:1594:1711:1730:1747:1777:1792:2110:2393:2559:2562:2693:2904:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3874:4250:5007:6119:6261:8660:8957:10004:10400:10848:11658:11914:12297:12760:13069:13071:13148:13230:13311:13357:13439:14096:14097:14180:14721:14827:21060:21080:21212:21433:21627:21740:21795:21809:21939:21990:30012:30051:30054, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: cakes33_4b0166a26eac X-Filterd-Recvd-Size: 1668 Received: from jonpc (cpc97974-croy24-2-0-cust112.19-2.cable.virginm.net [77.99.44.113]) (Authenticated sender: jon@beniston.com) by omf14.hostedemail.com (Postfix) with ESMTPA for ; Mon, 6 Jul 2020 13:16:06 +0000 (UTC) From: "Jon Beniston" To: References: In-Reply-To: Subject: RE: SIGINT lost while program calls PeekMessage Date: Mon, 6 Jul 2020 14:16:06 +0100 Message-ID: <02c901d65397$9c49fcf0$d4ddf6d0$@beniston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKJ7mrblqjmu3sNtiQYw6m3+0V3haeTTnXg Content-Language: en-gb X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 13:16:08 -0000 Hi Corinna, >Since your example code is running very tightly most of its time inside >some Windows system DLL function, there's next to no chance to interrupt >the thread to inject the signal handler call. Cygwin tries this 100 >times per signal. If that fails, the signal gets lost. > >One way to solve this problem is adding a Cygwin call into the loop, >like the aforementioned usleep. When a Cygwin call is performed, the >signal handler will be called as soon as the Cygwin call returns to >user-space. > >The bottom line is, Cygwin user space signal handlers and lots of >Windows-only calls in a tight loop don't work nicely together. Ok, thanks for the explanation. In the real application, there is some actual processing inside the loop, besides the call to PeekMessage and more signals get through (Probably 75%), I just cut the code down to make a simpler test case. I'll add a Cygwin call as suggested. Cheers, Jon