src-test/lib/libc/yp, branch stable/6FreeBSD source treehttps://cgit-dev.freebsd.org/src-test/atom?h=stable%2F62007-08-25T19:41:02ZMFC rev 1.51:2007-08-25T19:41:02ZSimon L. B. Nielsensimon@FreeBSD.org2007-08-25T19:41:02Zurn:sha1:dc9b7588d20bdb35480337bb8f26aa09603a2795
Set timeout for all NIS RPC requests to 1 second and not just for
yp_next as revision 1.50 did. This should fix, or at least very much
reduce the risk of, NIS timing out due to UDP packet loss for NIS
functions.
See also revision 1.50 for more details about the general problem.
MFC 1.50:2007-03-11T09:59:51ZSimon L. B. Nielsensimon@FreeBSD.org2007-03-11T09:59:51Zurn:sha1:7619493d5bfbe5de2d0985df8ded100e9bd8612f
- Bump _yplib_timeout limit from 10 to 20 seconds to better handle
packet loss when talking to a NIS server.
- Set 1 second retry timeout to further realistically handle UDP
packet loss for yp_next packet bursts. If the packet hasn't come
back within 1 second its rather unlikely to come back at all. There
is still back-off mechanism in RPC so if there is another reason
than packet loss for the lack of response within 1 second, the NIS
server will not be totally bombarded with requests.
This reduces the risk of NIS failing with:
yp_next: clnt_call: RPC: Timed out
considerably. This is mainly a problem if you have larger NIS maps
(like at FreeBSD.org) since enumerations of the lists will cause a UDP
packet bursts where a few packets being lost once in a while do
happen.
Discussed with: peter
Problem mainly diagnosed by: peter
do mutex lock for each yp calls. with this,2005-05-03T20:30:31ZHajimu UMEMOTOume@FreeBSD.org2005-05-03T20:30:31Zurn:sha1:d21de89a71f0c850e167d5cb1ca07c0ec4910bd6
http://cvsweb.netbsd.org/bsdweb.cgi/src/regress/lib/libpthread/resolv/
is working.
MUTEX_INITIALIZER should be used instead of2005-04-06T15:16:04ZHajimu UMEMOTOume@FreeBSD.org2005-04-06T15:16:04Zurn:sha1:1b482912d124eaa5e1c0abb83ef7cc87b9e205f1
PTHREAD_MUTEX_INITIALIZER, here.
protect _yp_domain with mutex lock.2005-04-05T18:07:59ZHajimu UMEMOTOume@FreeBSD.org2005-04-05T18:07:59Zurn:sha1:069eb2cafbd04644ab994cc2a7684b86f5c33447
Inspired by: NetBSD
Use socklen_t where appropriate.2005-03-11T14:17:12ZStefan Farfelederstefanf@FreeBSD.org2005-03-11T14:17:12Zurn:sha1:595e532309e983d7d6c86f88867f786b3ccaa756Back out the `hiding' of strlcpy and strlcat. Several people2003-05-01T19:03:14ZJacques Vidrinenectar@FreeBSD.org2003-05-01T19:03:14Zurn:sha1:d05090827f0e5b95cc7d2bcdde8b3b4e0f986241
vocally objected to this safety belt.
`Hide' strlcpy and strlcat (using the namespace.h / __weak_reference2003-04-29T21:13:50ZJacques Vidrinenectar@FreeBSD.org2003-04-29T21:13:50Zurn:sha1:5723e501abb675701352eb3e9fd58bb3cc2c649d
technique) so that we don't wind up calling into an application's
version if the application defines them.
Inspired by: qpopper's interfering and buggy version of strlcpy
libc_r wasn't so tied to libc for 22 months.2002-11-18T09:50:57ZRuslan Ermilovru@FreeBSD.org2002-11-18T09:50:57Zurn:sha1:c51d717f0c0adcb64bbf49ef373972c2367c50ecSpell void * as void * rather than caddr_t. This is complicated by the2002-04-28T15:18:50ZDag-Erling Smørgravdes@FreeBSD.org2002-04-28T15:18:50Zurn:sha1:f249dbcc7149848de00cd8f4e93fe140dfa3f219
fact that caddr_t is often misspelled as char *.
Sponsored by: DARPA, NAI Labs