Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Aug 2011 00:04:56 +0400
From:      Slawa Olhovchenkov <slw@zxy.spb.ru>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: sigwait return 4
Message-ID:  <20110824200456.GE48394@zxy.spb.ru>
In-Reply-To: <20110824195035.GA17489@deviant.kiev.zoral.com.ua>
References:  <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> <20110824195035.GA17489@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote:

> On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote:
> > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote:
> > 
> > > > > What should the system do for a delivered signal not present in the set ?
> > > > > I guess this is the case of your ktrace.
> > > > > 
> > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle
> > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely
> > > > > EINTR The wait was interrupted by an unblocked, caught signal.
> > > > 
> > > > I don't think you right in this case.
> > > > This is kas-milter and in this thread (this is multi-thread
> > > > application) kas-milter wait for USR2 for reload config.
> > > > 
> > > > System return from sigwait only on USR2, but not each return w/
> > > > non-zero return code.
> > > > 
> > > > On freebsd7 this application don't complain about sigwait's return value.
> > > 
> > > Could it be that some other thread has the signal unblocked ?
> > > (You can verify this with procstat -j).
> > > 
> > > Can you write the self-contained test case that demonstrates the behaviour ?
> > 
> > This is closed-source software.
> How is this statement related to the creation of the standalone test case ?

I don't know what testing.

> > # procstat -j
> >   PID    TID COMM             SIG     FLAGS
> >  1395 100199 kas-milter       USR2     --
> >  1395 100232 kas-milter       USR2     --
> 
> Both threads have the signal not blocked. This is not definitive,
> since signal must be blocked during the call to sigwait(2). Note that
> the SUSv4 says that "The signals defined by set shall have been
> blocked at the time of the call to sigwait(); otherwise, the behavior is
> undefined."

This is not suitable to return '4'.
And where root of this '4'?

In /sys/kern/kern_sig.c:sigwait we call

error = kern_sigtimedwait(td, set, &ksi, NULL); --- no timeout.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110824200456.GE48394>