Date: Thu, 17 Mar 2011 09:28:59 -0700 From: Yuri <yuri@rawbw.com> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-hackers@freebsd.org, standards@freebsd.org Subject: Re: Is pthread_cond_signal(3) man page correct? Message-ID: <4D8236CB.5010000@rawbw.com> In-Reply-To: <AANLkTinmbwb9JpPwz7qEx9nkgbjAXwf5H6CTrGEDed4u@mail.gmail.com> References: <4D6ABA14.80208@rawbw.com> <4D6AC17A.7020505@rawbw.com> <4D6B01DB.9090909@freebsd.org> <4D80D5E0.5080302@rawbw.com> <4D8169BF.6090503@freebsd.org> <AANLkTinmbwb9JpPwz7qEx9nkgbjAXwf5H6CTrGEDed4u@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D8236CB.5010000>