threads/94176: KSE: sigwait doesn't recieve SIGWINCH sent by pthread_kill() or kill -WINCH

eugeny gladkih john at
Fri Apr 28 09:50:22 UTC 2006

The following reply was made to PR threads/94176; it has been noted by GNATS.

From: eugeny gladkih <john at>
To: David Xu <davidxu at>
Cc: Andriy Gapon <avg at>, bug-followup at
Subject: Re: threads/94176: KSE: sigwait doesn't recieve SIGWINCH sent by pthread_kill() or kill -WINCH
Date: Fri, 28 Apr 2006 13:40:25 +0400

 >>>>> "DX" == David Xu <davidxu at> writes:
  AG> maybe it would be beneficial to the general programmer public to add
  AG> something similar to the NOTES section of the following man page to
  >> our AG> man page for sigwait:
  AG> Using the original example, it would mean adding something like the
  AG> following code to get the desired behavior:
  AG> void dummy_handler(int signum)
  AG> {
  AG> return;
  AG> }
  AG> void *thread(void* unused) {
  AG> struct sigaction sa;
  AG> sa.sa_handler = dummy_handler;
  AG> sigemptyset(&sa.sa_mask);
  AG> sa.sa_flags = 0;
  AG> sigaction(SIGWINCH, &sa, NULL);
  AG> .
  AG> .
  AG> .
  >> why so stupid code should be presented in all software wanted
  >> just to wait the signal? :(
  >> sigwait'ed signal is not ignored one! we DON'T ignore it we DO
  >> wait for it. I'm afraid there is another problem with SIGTERM
  >> which will terminate process. am I right, yeah?
  DX> hmm, there is always race condition between userland and kernel,
  DX> guess what will happen if your thread is executing userland code and
  DX> a signal is being delivered to the process whose action is IGNORE ?
  DX> you are not waiting for the signal.
  DX> the dummy signal action you have to install can only help you to catch 
  DX> bug if you forgot to mask it. in history, BSD throws aways signal
  DX> immediately if the signal action is IGNORE, otherwise an ignored signal
  DX> may cause a sleep to be interrupted, this can happen according to
  DX> current sleep queue code and signal code.
 well, Q&A department was wrong saying Solaris version works well. so,
 it's not FreeBSD problem, I can agree now. thanx, everybody!
 Yours sincerely, Eugeny.
 Doctor Web, Ltd.

More information about the freebsd-threads mailing list