On Thu, Aug 23, 2001 at 10:47:57PM -0700, Aaron Bannert wrote: > 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.
But, what do we do about the farm semantics when running on a non-threaded system? Do nothing? Ignore their parameters? That's not good (I'd say it violates principle of least surprise - we shouldn't change how we interpret a test based on the OS we are running on). A collective on a non-threaded system would do forks upon forks. On a threaded system, it'd be mpmt (what we'd expect). > 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 :) Yeah, I actually wrote that code before I even compiled. There was only one error in logic. Impressive. =) -- justin
