Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain rowe-clan.net from 64.202.165.233 cause and error)
Message-ID: <462365B9.9090502@rowe-clan.net>
Date: Mon, 16 Apr 2007 07:02:01 -0500
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To:  RQuadling@GoogleMail.com
CC: Rob Richards <rrichards@ctindustries.net>, 
 Ilia Alshanetsky <ilia@prohost.org>,
 Rasmus Lerdorf <rasmus@lerdorf.com>, 
 Matt Wilmas <php_lists@realplain.com>,
  internals@lists.php.net
References: <007b01c77735$89410420$0201a8c0@pc1> <46151547.6000505@lerdorf.com>	 <10845a340704050830p6611aa73n6f81806618d5072a@mail.gmail.com>	 <46153A67.3010208@ctindustries.net> <461541C1.4080404@lerdorf.com>	 <46155EC9.1020402@ctindustries.net>	 <10845a340704130333i17921209pad4538b5a3a43e7@mail.gmail.com>	 <3FD3996A-6E63-44BF-88EF-CEB174254995@prohost.org>	 <10845a340704130642w7c4edf5an8bc41d49c4e1dd86@mail.gmail.com>	 <4620B813.8080306@ctindustries.net> <10845a340704160155o18e0ef3dj135113d835e633d4@mail.gmail.com>
In-Reply-To: <10845a340704160155o18e0ef3dj135113d835e633d4@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Build failure
From: wrowe@rowe-clan.net ("William A. Rowe, Jr.")

On Windows, there is no such thing as a true open-write-for-append.

Unlike Unix, write for append mode is not atomic, internally it is a
seek + write.  Mix that with multiple writers, and you have an inherent
race condition built it.


Richard Quadling wrote:
> That's good news. Has a patch been submitted? Even if it is initially
> only a win32 compiler directive wrapping the lock?
> 
> On 14/04/07, Rob Richards <rrichards@ctindustries.net> wrote:
>> I can sometimes reproduce the missing entries though never get data
>> corruption anymore.
>> This might now be a Windows only issue with how it is caching writes. I
>> did a little debugging and no errors occurred.
>> The file was opened successfully every time, the data was written
>> (correct number of bytes as well) every single time, but depending upon
>> the load on my system at the time it was a crap shoot whether every
>> single write actually made it into the physical file or not. Adding a
>> lock here did resolve it so that it worked 100% of the time.
>>
>> Rob
>>
>> Richard Quadling wrote:
>> > So why are there missing entries?
>> >
>> > I can even get the corruption back again if I use a shorter line (100
>> > rather than 5000).
>> >
>> >
>> > On 13/04/07, Ilia Alshanetsky <ilia@prohost.org> wrote:
>> >> The new implementation does not use any locks, instead it uses direct
>> >> io, where locks are not necessary for append operations.
>> >>
>> >>
>> >> On 13-Apr-07, at 6:33 AM, Richard Quadling wrote:
>> >>
>> >> > On 05/04/07, Rob Richards <rrichards@ctindustries.net> wrote:
>> >> >> No difference using sprintf()/fwrite() instead of fprintf().
>> >> >>
>> >> >> I did come across a similar issue from apache:
>> >> >> http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/%
>> >> >> 3C9502272049.aa02036@paris.ics.uci.edu%3E
>> >> >>
>> >> >> Changing to use VCWD_OPEN_MODE, write() and close() seems to work.
>> >> >>
>> >> >> Rob
>> >> >>
>> >> >
>> >> > Using PHP 5.2.2RC2-dev (cli) (built: Apr 13 2007 04:03:02) on
>> >> > Windows with
>> >> >
>> >> > for %x in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
>> >> > start php -r "ini_set('error_log','/tmp/test.log');for($i=0;$i<1000;
>> >> > $i++)error_log(str_repeat('%x',5000));"`;
>> >> >
>> >> > And then doing some analysis of the log file I'm finding that not
>> all
>> >> > the data has been written.
>> >> >
>> >> > Array
>> >> > (
>> >> >    [A] => 4965993
>> >> >    [B] => 4590918
>> >> >    [C] => 4525905
>> >> >    [D] => 4695939
>> >> >    [E] => 4495899
>> >> >    [F] => 4710942
>> >> >    [G] => 4495899
>> >> >    [H] => 4645929
>> >> >    [I] => 4540908
>> >> >    [J] => 4580916
>> >> >    [K] => 4535907
>> >> >    [L] => 4470894
>> >> >    [M] => 4480896
>> >> >    [N] => 4550910
>> >> >    [O] => 4610922
>> >> >    [P] => 4500900
>> >> >    [Q] => 4630926
>> >> >    [R] => 4480896
>> >> >    [S] => 4500900
>> >> >    [T] => 4535907
>> >> >    [U] => 4630926
>> >> >    [V] => 4470894
>> >> >    [W] => 4645929
>> >> >    [X] => 4825965
>> >> >    [Y] => 4845969
>> >> >    [Z] => 4920984
>> >> > )
>> >> > Lines (Should be 26 * 1000) : 23973
>> >> > Longest (Should be 5024) : 5024
>> >> > Shortest (Should be 5024) : 5024
>> >> >
>> >> > Out of the 26,000 lines expected we are missing 2027 lines.
>> >> >
>> >> > So no corruption of the lines, just missing ones.
>> >> >
>> >> > The only explanation I can think of is that the locking is working,
>> >> > but nothing is waiting for the lock to become available.
>> >> >
>> >> > Richard.
>> >> >
>> >> >
>> >> > --
>> >> > -----
>> >> > Richard Quadling
>> >> > Zend Certified Engineer : http://zend.com/zce.php?
>> >> > c=ZEND002498&r=213474731
>> >> > "Standing on the shoulders of some very clever giants!"
>> >>
>> >> Ilia Alshanetsky
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
> 
>