Date: Fri, 30 Apr 2010 23:22:07 +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: <4BDB49FF.4000303@mysql.com> In-Reply-To: <20100429194932.GI14572@dan.emsphone.com> References: <4BD9D098.8010201@mysql.com> <20100429194932.GI14572@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan, thanks for your reply: 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 plat= forms, >> 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 thi= s many >> times before giving up. >> >> [[...]] >=20 > I'm pretty sure this is a holdover from when FreeBSD only had a use= r > pthreads package (libc_r). libc calls that would normally block go= t > converted into non-blocking versions and a select() loop would exec= ute > threads as the events they were waiting on occurred. Incoming sign= als would > cause all threads waiting on read() to return EINTR. If you have o= ther > threads doing work and sending/receiving signals, this can add up t= o a lot > of extra EINTR's. Interesting information - thanks. I never heard that before, but it explains a lot. >=20 > FreeBSD 5.0 (released in 2003) was the first version to have kernel= -based > pthread support, so the original reason for raising net_retry_count= has long > since disappeared. It is quite possible that nobody checked this: "If it ain't broken ..." >=20 > A related question might be, though: Should that variable even exi= st?=20 > EINTR isn't technically a failure, and most programs that read from= sockets > simply wrap their read()s in a loop that retries when EINTR is rece= ived.=20 > Only mysql actually counts the number of times through the loop. I know and agree that EINTR is no failure if a system call takes long= , like read() or write() from/to a socket (or other slow device) on sufficiently large data. But my current action is not to change the code, rather it is a clean= up in the build system (you may have heard we are changing from the autotools to cmake), so currently I won't change that loop dealing wi= th possible system call interruptions (by not counting). So you are saying it might all be obsolete, and current versions of FreeBSD don't need this special setting. This sounds like I should do a build without it and then run tests. T= hanks! Regards, J=F6rg --=20 Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@Sun.COM 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?4BDB49FF.4000303>