Date: Thu, 8 Apr 1999 13:06:31 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: Tony Finch <dot@dotat.at> Cc: smp@FreeBSD.ORG Subject: Re: concurrent select()s on listen socket broken under SMP Message-ID: <Pine.BSF.4.05.9904081304480.15426-100000@alive.znep.com> In-Reply-To: <E10VKig-0006Y3-00@fanf.noc.demon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Apr 1999, Tony Finch wrote: > 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. There is a race condition in the idea that having multiple processes doing a select() then an accept() on the same descriptor should always result in an accept() for each success from accept(). It is not an OS problem, although various OSes may behave in different ways. This is one of the reasons why Apache uses an "accept mutex". It essentially does the same thing if you have multiple listening sockets. 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?Pine.BSF.4.05.9904081304480.15426-100000>