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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
