Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 May 2010 01:09:49 +0200
From:      Joerg Bruehe <joerg@mysql.com>
To:        Dan Nelson <dnelson@allantgroup.com>
Cc:        FreeBSD-Questions <freebsd-questions@freebsd.org>
Subject:   Re: Need info about FreeBSD and interrupted system calls for MySQL code
Message-ID:  <4BDB633D.6060509@mysql.com>
In-Reply-To: <20100430221418.GJ14572@dan.emsphone.com>
References:  <4BD9D098.8010201@mysql.com> <20100429194932.GI14572@dan.emsphone.com> <4BDB49FF.4000303@mysql.com> <20100430221418.GJ14572@dan.emsphone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Dan,


your info is very valuable - thanks:

Dan Nelson wrote:
> 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 platfo=
rms,
>>>> 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).  [[...]]
>> Interesting information - thanks. I never heard that before, but it
>> explains a lot.
>=20
> This may also have been due to a bug in the early libc_r code.  Appropr=
iate
> 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 ancien=
t
> mysql source code around (3.22 and 3.23 era), but have since deleted th=
em,
> so I don't know when the 1000000 workaround was added.

The readily available revision control history of the MySQL source code
goes back to the year 2000 only (the system used was changed back then,
without history transfer), but a colleague checked that this workaround
is documented in the manual of 3.22.

All this seems to be a good indication we should get rid of this.


Thanks for your help,
J=F6rg

--=20
Joerg Bruehe,  MySQL Build Team,  Joerg.Bruehe@Sun.COM
               (+49 30) 417 01 487
Sun Microsystems GmbH,   Komturstrasse 18a,   D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz
Amtsgericht Muenchen: HRB161028




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BDB633D.6060509>