Subject: CVS commit: [netbsd-3-0] src/lib/libpthread
To: None <source-changes@NetBSD.org>
From: Matthias Scheler <tron@netbsd.org>
List: source-changes
Date: 06/13/2006 22:31:30
Module Name:	src
Committed By:	tron
Date:		Tue Jun 13 22:31:30 UTC 2006

Modified Files:
	src/lib/libpthread [netbsd-3-0]: pthread_sig.c

Log Message:
Pull up following revision(s) (requested by chuck in ticket #1376):
	lib/libpthread/pthread_sig.c: revision 1.46
sigtimedwait: if we collect a queued signal via pt_siglist, do not
forget to clear it out of pt_siglist, otherwise we will keep getting
it over and over again.   fixes a problem introduced in rev 1.43.
problem observed with mysqld where sending it a SIGHUP after it has
set an alarm (e.g. due to some package like rt3 using it) caused the
signal handler thread to go into a tight loop (collecting a SIGALRM
[via sigwait() in mysqld.cc] that would not go away due to the above
issue).   mysqld appears to get a SIGHUP when /etc/rc exits, so it
can go into this tight loop after a reboot (but not if you restart
it by hand).   the bad sequence is:
        /etc/rc runs:
                - starts mysqld
                - starts web server with rt3 fastcgi starts
                - fastcgi/rt3 talks to mysqld (causing it to set an alarm)
                - /etc/rc exits, SIGHUP goes to mysqld
                - mysqld catches SIGHUP, signal handler thread gets
                        stuck in loop (database continues to operate, slowly).
you can also trigger the problem by sending mysqld a SIGHUP by hand after
you've caused it to set an alarm by connecting to it.


To generate a diff of this commit:
cvs rdiff -r1.39.2.3 -r1.39.2.3.2.1 src/lib/libpthread/pthread_sig.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.