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 dnel...@allantgroup.com _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"