Re: fflush and fsync
Date: Tue, 22 Apr 2008 03:07:12 +0200
2008/4/21, Dan Fandrich wrote:
> The new fflush and fsync calls that have been added to the test server
> are checked in configure and only used if found.
Yep that's it, I have no intention at all of including it for
lib/curl. This was a test harness only 'fix'.
At this moment I've only introduced it for the sws test harness
server, which is the only one which at this moment seemed to get a
benefit of doing so. More details later.
> fflush is part of ANSI C, so that's safe to use unconditionally.
> fsync shouldn't even be needed within curl. Whether log files
> are physically on disk or merely in the cache should have no
> effect on the success of any curl operation. Is that call actually
As long as fflush() makes changes visible to other processes there is
no need for fsync(). But if fflush() + fclose() don't make changes
immediately visible to other processes, then on those OS test harness
would certainly benefit using fsync().
> The only time I can see that having an effect is when running the
> curl test suite on a remote machine, which doesn't quite work properly
> without some hacks, anyway.
Ok, lets see...
Test # 1001 was failing verification on some systems due to the fact
that test harness sws server was completing the writing of the server
input request file once that runtests.pl had already read it and
compared its incomplete contents with the expected results. Resulting
in a false test failure.
First step taken. Introduce a small delay in the <postcheck> section
ot test # 1001. This proved to be effective on autobuilds since it no
Second step taken. fflush() + fsync() immediately before fclose(), and
not after every fwrite(), to accelerate writing of server input and
response request files for test harness sws server. This combined with
first step obviously proved effective and test 1001 didn't fail.
Third step taken. Remove first step to verify if second one alone is
enough. This has just been committed. So no autobuild test results
available yet. :-)
So from this point on everything is conditional.
If removal of the extra delay for 1001 makes it fail again even with
fflush() + fsync() in place, then the fflush() + fsync() must be
removed and the delay introduced again for 1001.
If 1001 does not fail with fflush() + fsync() in place and no extra
delay. Then we can wave goodbye to the 1001 extra delay.
In this last case then we could also remove fsync() and verify results again.
For others reading this: It is important to notice that fflush() +
fsync() is not being called for every fwrite(), only before flcose().
-- -=[Yang]=-Received on 2008-04-22