Date: Thu, 8 Apr 1999 15:59 EDT From: Barney Wolff <barney@databus.com> To: smp@freebsd.org Subject: Re: concurrent select()s on listen socket broken under SMP Message-ID: <370d0b3a0.466c@databus.databus.com>
next in thread | raw e-mail | index | archive | help
Seems to me you need to set the socket non-blocking, and then handle the EWOULDBLOCK on the fd that loses. I don't think this should be considered a kernel error. Barney Wolff <barney@databus.com> > From: Tony Finch <dot@dotat.at> > Date: Thu, 8 Apr 1999 20:44:10 +0100 > > We discovered something odd this evening: > > We have a modified thttpd which forks several times between opening > its listen socket and dropping into the big select() loop. There is a > difference in behaviour between uniprocessor machines and SMP machines > when a connection arrives. > > On a uniprocessor machine, select() only tells one process that a > connection is available. On a dual processor machine, two processes > are told that a connection is available: both processes then go on to > accept() the connection and one of them succeeds but the other blocks. > This upsets thttpd greatly because it expects the accept() to be > instantaneous for the purpose of calculating timeouts. > > Because we are on a bastard deadline our current fix is to use a > uniprocessor kernel, but this is a little bit wasteful. A fix would be > nice... > > Tony. > -- > f.a.n.finch dot@dotat.at fanf@demon.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?370d0b3a0.466c>