httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: cvs commit: httpd-test/flood 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:47:57 GMT
On Thu, Aug 23, 2001 at 10:35:50PM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 24, 2001 at 04:26:39AM -0000, wrote:
> > jerenkrantz    01/08/23 21:26:39
> > 
> >   Modified:    flood 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

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 :)


View raw message