From owner-freebsd-standards@FreeBSD.ORG Thu Mar 17 16:29:00 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E4E106566B; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7828FC0A; Thu, 17 Mar 2011 16:29:00 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p2HGPPum040853; Thu, 17 Mar 2011 09:25:25 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4D8236CB.5010000@rawbw.com> Date: Thu, 17 Mar 2011 09:28:59 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: Garrett Cooper References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:29:00 -0000 On 03/16/2011 19:20, Garrett Cooper wrote: > So yes, EINTR not being allowed is by design and this backs up what > davidxu@ is stating above. Our manpage just doesn't explicitly call > this requirement out, unlike a Linux manpage I dug up and the > OpenGroup manpage. > I apologize for keeping asking, but David Xu mentioned before that signal can also be delivered at the same time and pthread_cond_signal will exit. Normally its EINTR (like for open(2)). But now you are saying that EINTR isn't allowed for pthread_cond_signal. So does this mean that signal can't be delivered during pthread_cond_signal, or it will just return 0? In the latter case, how can I distinguish signal delivery and successful return? Yuri