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:mime-version :content-type; q=dns; s=default; b=KWG2lWekbzUs0PxfxRHIrYfVkzspW IeEiOonZmmbHRyMK8S8+bdfy4T7RtVCH4cBJnJNmrpontcHXVteLuP3fSuLitqqT oG2WH8Lzx3M5hmU7xB+YoJuy+OqvE+sH/myYnDQ4aZVO0Llz5lLT9cRr+5DMD2fp wtmRkrKhVACWTs= 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:mime-version :content-type; s=default; bh=F+xhlPeNDsp3zloXyoXRIWHo0Is=; b=QAN hGUa8046C8Hv0YneYyiORoV8XX7itYpEW5vTEmJ/CyqLINWSjKE8YLO8D/NN04sn LSEsjxCSvSQ+kHco28PXqbW/4CMxYJgS7w+NBQcSK/PrHEcg7QM82JT2AEuI1Tel /GMHDispEatarOKWgIGGdSycFq2sDfMwo+8uj1+g= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 spammy=H*F:D*ne.jp, UD:ne.jp, resumes, D*ne.jp X-HELO: conssluserg-06.nifty.com DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com v27BhHNg004081 X-Nifty-SrcIP: [175.179.23.201] Date: Tue, 7 Mar 2017 20:43:18 +0900 From: Takashi Yano To: cygwin AT cygwin DOT com Subject: Changing behaviour of pthread_cond_wait(). Message-Id: <20170307204318.8dda1744403eafdb79e2cf06@nifty.ne.jp> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__7_Mar_2017_20_43_18_+0900_WHN_arJRDl+j3mFs" X-IsSubscribed: yes --Multipart=_Tue__7_Mar_2017_20_43_18_+0900_WHN_arJRDl+j3mFs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I would like to propose chaging behaviour of pthread_cond_wait(). POSIX states as follows about pthread_cond_wait(): If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it returns zero due to spurious wakeup. cygwin 2.7.0 employs the latter behaviour, while Debian GNU/Linux and FreeBSD employ the former one. Of course, this is not a cygwin bug. However, IMHO, it is better to have the compatibility with the other major platforms. Because of this difference, iperf 2.0.5 is not terminated normally in cygwin 2.7.0. In client mode, iperf 2.0.5 does not stop after measurement automatically. It needs ^C to stop it. In server mode, iperf 2.0.5 can not stop even by ^C. Simple test case, attached (pt.c), reproduces this problem. I know this test case (and iperf 2.0.5) is essentially unsafe because pthread functions are called from signal handler. But, anyway it works in Debian GNU/Linux and FreeBSD. The test case acts as follows in Debian GNU/Linux and FreeBSD. % gcc pt.c -lpthread; ./a.out Thread 1 Alarm 2 Thread 3 % However, in cygwin, it acs as: % gcc pt.c; ./a.exe Thread 1 (Deadlock: ^C is needed to terminate.) % I would like to propose a patch attached (pthread.patch), for the above reason. With this patch, iperf 2.0.5 as well as the test case works fine. -- Takashi Yano --Multipart=_Tue__7_Mar_2017_20_43_18_+0900_WHN_arJRDl+j3mFs Content-Type: text/x-csrc; name="pt.c" Content-Disposition: attachment; filename="pt.c" Content-Transfer-Encoding: 7bit #include #include #include #include pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t c; int flag = 0; #define N 2 void sig_handler(int sig) { pthread_mutex_lock(&m); flag ++; pthread_cond_signal(&c); printf("Alarm %d\n", flag); fflush(stdout); pthread_mutex_unlock(&m); } void *thread_main(void *args) { int i; for (i=0; i