Subject: Re: Win32 Progress Report
To: new-httpd@hyperreal.com
Date: Sun, 4 Aug 1996 15:30:55 +0100 (BST)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
In-Reply-To: <199608041437.KAA15513@volterra.ai.mit.edu> from "Robert S. Thau"
 at Aug 4, 96 10:37:54 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2477      
Message-ID: <9608041530.aa26088@gonzo.ben.algroup.co.uk>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Robert S. Thau wrote:
> 
>   So am I with it or out in left field????
> 
> Well, let's see.  You're arguing for a major change in the way the server
> is structured (people have explicitly brought up the notion of more minor
> changes, and you have rejected the notion) --- a structure which has
> served us well, for some time.
> 
> The motive for these changes is apparently to improve portability.
> Yet, in the post to which I'm responding (and the others which I've
> read), you don't offer any *specific* arguments for why the structure
> you propose is really necessary to support ports which we might
> actually want to do.  (Adding hooks we're never going to use is pretty
> clearly a bad idea --- it can *only* cause us problems).  In fact, we
> have some evidence (from Ben's preliminary work, and the earlier OS/2
> port) that it is *not* necessary.  As this goes on, I see more and
> more details about "the proposal", but I don't see much at all about
> why any of them are actually necessary.

Actually, I have some sympathy for "the proposal" but don't see it as necessary
for the job in hand. I do think that a certain amount of the OS/2 messiness
could be avoided with some OS-specific hooks here and there.

> 
> So yes, I think you're out in left field.
> 
> BTW, on another issue, the main work items it would take to port the
> existing apache-XX code on top of a preemptive threads package are:
> 
>   1) Missing locks on storage management (currently not needed
>      because of the nonpreemptive nature of rsthreads).
> 
>   2) Dealing sfio --- this is probably best dealt with by simply
>      moving to another stdio replacement which provides equivalent
>      functionality and *is* preemption-safe, such as the hacked
>      Berkeley stdio which comes with Chris Provenzano's pthreads
>      package (which is therefore an obvious first target for such a
>      port).

Grrrk. You are depressing me. Is this really going to be any easier than
safing sfio? Or, to put it another way, do you plan to make this change in the
near future?

Cheers,

Ben.

> 
> I see no reason why a massive reorganization of the source code
> would be required.
> 
> rst

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)