From owner-freebsd-smp  Thu Apr  8 13:51: 0 1999
Delivered-To: freebsd-smp@freebsd.org
Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132])
	by hub.freebsd.org (Postfix) with ESMTP id B82DB14E67
	for <smp@freebsd.org>; Thu,  8 Apr 1999 13:50:44 -0700 (PDT)
	(envelope-from fanf@chiark.greenend.org.uk)
Received: from fanf by chiark.greenend.org.uk with local (Exim 2.02 #1)
	id 10VLj4-0001LF-00 (Debian); Thu, 8 Apr 1999 21:48:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14093.5670.813002.917842@chiark.greenend.org.uk>
Date: Thu, 8 Apr 1999 21:48:38 +0100 (BST)
From: Tony Finch <dot@dotat.at>
To: Marc Slemko <marcs@znep.com>
Cc: Tony Finch <dot@dotat.at>, smp@FreeBSD.ORG
Subject: Re: concurrent select()s on listen socket broken under SMP
In-Reply-To: <Pine.BSF.4.05.9904081304480.15426-100000@alive.znep.com>
References: <E10VKig-0006Y3-00@fanf.noc.demon.net>
	<Pine.BSF.4.05.9904081304480.15426-100000@alive.znep.com>
X-Mailer: VM 6.47 under Emacs 19.34.1
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Marc Slemko writes:
> 
> 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.

Ah, I have heard of this before then, although I didn't think it would
have this kind of effect. I had a quick dig around the kernel code to
see if there were any likely changes that I could make. What breaks if
I change the wakeup((caddr_t)&sb->sb_cc); in sowakeup() (line 319 of
uipc_socket2.c) to a wakeup_one()?

Tony.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message