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 Message-ID: <14093.5670.813002.917842@chiark.greenend.org.uk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14093.5670.813002.917842>