Date: Sat, 31 May 1997 11:25:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: luigi@labinfo.iet.unipi.it, julian@whistle.com, julian@alpo.whistle.com, hackers@FreeBSD.ORG Subject: Re: WHy does Appache eat my system? Message-ID: <199705311825.LAA10995@phaeton.artisoft.com> In-Reply-To: <199705311205.OAA22027@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 31, 97 02:05:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705311825.LAA10995>