On Thu, Aug 23, 2001 at 10:35:50PM -0700, Justin Erenkrantz wrote: > On Fri, Aug 24, 2001 at 04:26:39AM -0000, [EMAIL PROTECTED] wrote: > > jerenkrantz 01/08/23 21:26:39 > > > > Modified: flood config.h.in configure.in flood.c > > flood_easy_reports.c flood_farm.c flood_net.c > > flood_net_ssl.c flood_report_relative_times.c > > Log: > > Per Sander, Linux 2.4 returns EAGAIN when we run out of ports. > > This was a royal screw-up on my part. I only meant to commit > flood_net.c, but all of the fork stuff slipped in. It wasn't > really ready for commit. But, uh, yeah, it's there now. =) > > I'll test it some more (it works) and then I'll commit lines to CHANGES > with what I really changed on this commit. *sigh* -- justin
After looking through the changes I'm not so sure this is what we want. I'd rather not treat threads and forked processes the same, since we may want to mix the two. The fork()ed scenario was what we originally defined as a "collective", which is basicly a bunch of "farms" with each "farm" running in a single process. I'm worried that we're losing flexibility here, at least in terms of properly emulating some real-world clients (like a browser that truely uses threads). This may just be invalid paranoia on my part, but at this time I see no good reason to restrict ourselves. I like using conditional compilation for things like optimizing OpenSSL usage, but I don't like it for deciding what a "farmer" does. Anyway, I realize that this was a premature commit, but I thought I'd voice my objections anyway ;) BTW, I'm glad to see we're going to support fork()ing soon :) -aaron
