Need info about FreeBSD and interrupted system calls for MySQL code

Dan Nelson dnelson at allantgroup.com
Fri Apr 30 22:14:21 UTC 2010


In the last episode (Apr 30), Joerg Bruehe said:
> Dan Nelson wrote:
> > In the last episode (Apr 29), Joerg Bruehe said:
> >> For some long, unknown time, the MySQL code contains a variable
> >> "net_retry_count" which is by default set to 10 (ten) for all platforms,
> >> but to 1000000 (1 million) for FreeBSD (during configure phase).
> >>
> >> The source code comment about this variable reads
> >>        If a read on a communication port is interrupted, retry this many
> >>        times before giving up.
> >>
> >> [[...]]
> > 
> > I'm pretty sure this is a holdover from when FreeBSD only had a user
> > pthreads package (libc_r).  libc calls that would normally block got
> > converted into non-blocking versions and a select() loop would execute
> > threads as the events they were waiting on occurred.  Incoming signals
> > would cause all threads waiting on read() to return EINTR.  If you have
> > other threads doing work and sending/receiving signals, this can add up
> > to a lot of extra EINTR's.
> 
> Interesting information - thanks. I never heard that before, but it
> explains a lot.

This may also have been due to a bug in the early libc_r code.  Appropriate
use of sigwait() and pthread_sigmask() should let the pthreads library know
which read() calls it can silently retry on behalf of threads that are
ignoring signals (and thus shouldn't have their syscalls aborted with
EINTR).  I have email records talking about libc_r problems with signal
masking from the FreeBSD 2.2.7 days (~1998).  It's possible that later
libc_r versions had fixed the bug.  I used to have copies of the ancient
mysql source code around (3.22 and 3.23 era), but have since deleted them,
so I don't know when the 1000000 workaround was added.

-- 
	Dan Nelson
	dnelson at allantgroup.com


More information about the freebsd-questions mailing list