Date: Sat, 27 Aug 2011 16:25:36 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-stable@freebsd.org, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: sigwait return 4 Message-ID: <20110827142536.GA66167@stack.nl> In-Reply-To: <20110824212929.GC17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> <20110824212929.GC17489@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > > up in r219709). The discussion started at > > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html > > > > Solaris is simply wrong in the same way we were wrong. Although POSIX > > may not be as clear on this as one may like, its intention is clear and > > additionally not returning EINTR reduces subtle portability problems. > Can you, please, describe why do you consider the behaviour prohibiting > return of EINTR reasonable ? I do consider that the Solaris behaviour is > useful. Applications need to cope with EINTR returns (usually by retrying the call); if they do not do this, bugs arise in uncommon cases. In the case of sigwait(), applications do not really need EINTR: they can include the respective signal into the signal set and do the work inline that was originally in the signal handler. This might require additional pthread_sigmask() calls. This also fixes the race condition almost always associated with EINTR. Historically, this is because sigwait() came with POSIX threads, which also explains why it returns an error number rather than setting errno. The threads group considered EINTR errors not useful enough, given that they may lead to subtle bugs. This is fully standardized for functions like pthread_cond_wait() and pthread_mutex_lock(). In the case of sigwait(), it also plays a role that glibc has decided not to return EINTR, so that returning EINTR may lead to subtle bugs appearing on FreeBSD in software originally written for GNU/Linux. The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime and therefore follow different conventions. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110827142536.GA66167>