Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Apr 1999 17:04:27 -0400 (EDT)
From:      "Robert S. Sciuk" <rob@ControlQ.com>
To:        Tony Finch <dot@dotat.at>
Cc:        Marc Slemko <marcs@znep.com>, smp@FreeBSD.ORG
Subject:   Re: concurrent select()s on listen socket broken under SMP
Message-ID:  <Pine.UW2.3.96.990408170026.12803A-100000@fatlady.controlq.com>
In-Reply-To: <14093.5670.813002.917842@chiark.greenend.org.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.UW2.3.96.990408170026.12803A-100000>