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