On Thu, Aug 23, 2001 at 10:54:35PM -0700, Justin Erenkrantz wrote: > 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).
I agree, and that's probably why I put off doing it in the first place :) I think my solution was to just drop down and do the farm tests in serial. I've never heard of the principle of least surprise, what do you mean? We document how it's supposed to work (*before we write it, hopefully*) then if it doesn't work the way we said it would you are allowed to be surprised. > 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 thought mpmt was what we were striving for all along for platforms that could support it. *BSD is the only platform we're really worried about WRT threads, no? Let me put it a different way. I'm fine with the idea of interchanging threads with processes for running "farmers" as long as that satisfies all of our requirements. I don't think our requirements are limited to "make the damn fastest load-testing harness you can possibly make". I want it to also include "and make sure it can match real-world clients as much as possible". If you think we can emulate the typical 4-threaded GUI browser by treating threads and processes the same, then I am totally cool with that. > > 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 not bad :) -aaron
