httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: httpd-test/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
Date Fri, 24 Aug 2001 05:54:35 GMT
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, jerenkrantz@apache.org 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


Mime
View raw message