In the last episode (Nov 14), Erik Price said:
> > What OS do you use ?
> > The behaviour you're describing I've seen two-three years ago on
> > FreeBSD due to some bug/deficiency in FreeBSD threads. Since then
> > it was fixed (in FreeBSD I mean).
> Interesting! I'm using Darwin 1.3.1 (from Mac OS X 10.1.0), which
> was partly derived from one of the BSDs (I think it was FreeBSD in
> fact). What was the fix that was used? Maybe I can get it to apply
> to this situation.
There were fixes to both FreeBSD's libc_r and mysql. I was part of the
original discussion and have the thread archived. The only way for a
threaded program to reliably process signals is for all threads but one
to ignore the signal. Older versions of mysql used SIGQUIT to
shutdown, and never explicitly registered a signal handler. This
caused problems if the mysql startup script explicitly ignored SIGQUIT
(which it did on FreeBSD via the nohup command). Then there was a
libc_r bug where even if the signal got delivered, mysql never actually
In Mysql 3.22.11, the signal was changed to SIGTERM and a signal
handler was explicitly installed. As far as libc_r patches, there are
two candidates. One is a 50-line commit on 1998-11-15 with the comment
"Interrupt threads waiting in select etc.". There was another large
(2000-line) commit on 1999-07-23 with the comment "MFC: Bring in both
bug fixes, performance improvements, and enhancements. This should fix
MySQL problems". The commit went in between the releases of FreeBSD
3.2 and 3.3. I don't know exactly what version of code Apple used for
Darwin, or how easy it would be to merge those changes into Darwin's
libc_r if they're not already in there. Darwin might not even be using
FreeBSD's thread library.