From owner-freebsd-smp Thu Apr 8 13: 4:13 1999 Delivered-To: freebsd-smp@freebsd.org Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by hub.freebsd.org (Postfix) with SMTP id CECB114D57 for ; Thu, 8 Apr 1999 13:04:08 -0700 (PDT) (envelope-from barney@databus.databus.com) From: Barney Wolff To: smp@freebsd.org Date: Thu, 8 Apr 1999 15:59 EDT Subject: Re: concurrent select()s on listen socket broken under SMP Content-Length: 1314 Content-Type: text/plain Message-ID: <370d0b3a0.466c@databus.databus.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 > From: Tony Finch > 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