Date: Thu, 8 Apr 1999 15:10:13 -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.9904081452120.15426-100000@alive.znep.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()? That could just break a whole lot of things I think. For example, if you have two processes in a select(), and two descriptors are ready, then only one process may return from the select with two descriptors ready, then proceed to handle one, while the other process sits there sleeping until something else wakes it up. In real life, this could lead to starvation. You also need to consider possible other starvation issues (which, in some situations, may actually be beneficial to performance) that could result in unfair distribution of connections between processes. The basic reason behind this is (aside from the non-standard behaviour and fairness issues) is that select() can notify a process that multiple sockets are ready to be dealt with, while a process will probably only be able to deal with one at a time. But I'm no expert. 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.9904081452120.15426-100000>