From owner-freebsd-smp Thu Apr 8 13:57:53 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpha.netaccess.on.ca (netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (Postfix) with ESMTP id B352214F3D for ; Thu, 8 Apr 1999 13:57:43 -0700 (PDT) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial143.netaccess.on.ca [204.101.178.98]) by alpha.netaccess.on.ca (8.8.5/8.7.3) with SMTP id QAA27806; Thu, 8 Apr 1999 16:55:20 -0400 (EDT) Date: Thu, 8 Apr 1999 17:04:27 -0400 (EDT) From: "Robert S. Sciuk" To: Tony Finch Cc: Marc Slemko , smp@FreeBSD.ORG Subject: Re: concurrent select()s on listen socket broken under SMP In-Reply-To: <14093.5670.813002.917842@chiark.greenend.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Apr 1999, Tony Finch wrote: > 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()? Why not do it and see what breaks?? Just kidding ... you may want to re-consider the suggestion of putting a mutex around the accept ... use SYSVSEM's for portability just in case this behaviour is apparent on other OS'es ... You'll serialize on the accept, but hey! you need to do that anyways. man semop() semctl() semget() This way you won't have to suffer the consequences of an obscurely hacked kernel, nor do you have to explain to your customer why a kernel rebuild is neccessary to install an application 8-). IMHO anyways ... Cheers, Rob. > > Tony. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. PO Box 6A Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message