Re: [PATCH] Re: Time to roll the 1.3.10 tarball

[Martin Kraemer <Ma...@Mch.SNI.De>]

-1 on this. You cannot make changes all over the place which break
on unix, only to make it run on windows. Yes you can, but then
you must #ifdef WIN32 it.

Like for instance...
    previously, a cache file was opened (tests existance), then
    its modification was derived using fstat (cheap operation because
    the inode is in the buffer cache) and then the first line was
    read.

    now, you stat() the file (tests existance and gets mod times),
    THEN you fopen() it (but it may no longer be the same file because
    another process might have unlinked() and replaced it) and
    then you read the first line. This is more than about twice as
    expensive as the previous solution, therefore I veto it (because
    the cache has millions of files, so I DO care).

> Here are the broken out patches, in unified diff format

And please submit the individual patches (yes, that was good) in the
correct MIME type (text/plain comes to mind, not application/octet-stream)
to make it easier to review them. Thank you.


> tls.patch allows the proxy module to be loaded dynamically under
> windows 95.

I'm not sure how many of the patches are already in a #ifdef WIN32
block. If they aren't, then things like TLS will be difficult (if
it compiles at all, then it will be less performant).

    Martin
-- 
  <Ma...@MchP.Siemens.De>      |       Fujitsu Siemens
       <ma...@apache.org>              |   81730  Munich,  Germany

Re: [PATCH] Re: Time to roll the 1.3.10 tarball

[David Whitmarsh <da...@dial.pipex.com>]

On Wed, 15 Dec 1999 23:44:58 +0100, you wrote:

>-1 on this. You cannot make changes all over the place which break
>on unix, only to make it run on windows. Yes you can, but then
>you must #ifdef WIN32 it.
>
>Like for instance...
>    previously, a cache file was opened (tests existance), then
>    its modification was derived using fstat (cheap operation because
>    the inode is in the buffer cache) and then the first line was
>    read.
>
>    now, you stat() the file (tests existance and gets mod times),
>    THEN you fopen() it (but it may no longer be the same file because
>    another process might have unlinked() and replaced it) and
>    then you read the first line. This is more than about twice as
>    expensive as the previous solution, therefore I veto it (because
>    the cache has millions of files, so I DO care).
>

Fair enough. Easily fixed.
>
>And please submit the individual patches (yes, that was good) in the
>correct MIME type (text/plain comes to mind, not application/octet-stream)
>to make it easier to review them. Thank you.

A pleasure.

>
>I'm not sure how many of the patches are already in a #ifdef WIN32
>block. If they aren't, then things like TLS will be difficult (if
>it compiles at all, then it will be less performant).

tls is very win32 specific and is ifdef'd.

gc_fix is now ifdef'd. gc_thread is ifdef'd where necessary. I don't
think there is anything else in there that would affect functionality
under unix

child_args.patch affects a chunk of code that is already WIN32
specific.

************************************

David Whitmarsh

Sparkle Computer Co Ltd

Sybase C C++ perl UNIX NT

************************************