From owner-freebsd-hackers Sat May 31 11:28:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02646 for hackers-outgoing; Sat, 31 May 1997 11:28:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02641 for ; Sat, 31 May 1997 11:28:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10995; Sat, 31 May 1997 11:25:19 -0700 From: Terry Lambert Message-Id: <199705311825.LAA10995@phaeton.artisoft.com> Subject: Re: WHy does Appache eat my system? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sat, 31 May 1997 11:25:19 -0700 (MST) Cc: luigi@labinfo.iet.unipi.it, julian@whistle.com, julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199705311205.OAA22027@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 31, 97 02:05:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The best one can do is (probably) to implement a modified select() > > which only wakes up the first process blocked (hoping it will be able > > to complete the accept() successfully). Maybe this is not too hard, but > > it is non-standard. > > After looking at /sys/kern/kern_synch.c , I think the modified select I > suggest is quite difficult to implement without major changes to the > kernel. > > First of all, all processes doing a select do a tsleep on the same > wchan, &selwait. > > Secondly, the identifier used in tsleep/wakeup is actually hashed > and collisions might occur. Since the hash table is relatively > small (128 entries) collisions are not that unlikely. This is an error. The usage of the tsleep() family of functions requires that a unique sleep address be treated uniquely. I think maybe you are misreading the code. > For both reasons, waking up only one process with a wakeup might > likely fail to get up the correct one. SVR4 implements a "wakeone" function in addition to "wakeup". For the reasons noted in my other post, this is not an optimal soloution. Since Julian is the guy who *invented* the framework in which an optimal soloution could be implemented, I'll leave it as an exercise for the Julian. 8-). > I think it would be nice to have a more effective mechanism to > implement multiple servers on the same port (the problem is the same > for httpd, nfsiod and probably others) but that needs a careful design > first. It's called a "mux" and Julian's code supports doing *exactly* that; he's just not using it. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.