On 3/21/2017 11:58 AM, James Richters wrote:
I have not tried FlushFileBuffers() yet, so I just tried it now, I am getting
the same results.
Well, that is expected, as the issue has nothing to do with your
program, it's the caching of the operating system that is responsible
for the actual ph
On 21 Mar 2017 18:59, "James Richters"
wrote:
I have not tried FlushFileBuffers() yet, so I just tried it now, I am
getting the same results. I have also tried disabling write caching in
disk management and STILL have the same results. I am now thinking this
is some caching being done on the
On 21/03/17 20:48, Marco van de Voort wrote:
He closes the file. That should sync.
Not necessarily. On Unix there is also a difference between closing a
file and calling fsync() on it. And even then there are sometimes
additional things you may have to do to survive sudden power loss, such
a
In our previous episode, Henry Vermaak said:
> > Writeln file
> > Writeln file ...
> > Flush file
>
> Have you tried using the FlushFileBuffers() Windows API? Something like
> this:
>
> FlushFileBuffers(TextRec(AFile).Handle);
>
> Add "windows" to the uses clause, obviously.
He closes the file
I have not tried FlushFileBuffers() yet, so I just tried it now, I am getting
the same results. I have also tried disabling write caching in disk
management and STILL have the same results. I am now thinking this is some
caching being done on the SSD that is ignoring FlushFileBuffers() Pro
On 21/03/17 15:39, James Richters wrote:
If I then power off the test computer (not doing a correct windows shutdown,
this simulates an unattended power failure) when it boots back up, my file
has the correct date and time and the correct length, hovever the contents
of the file is a string of $0
On Tue, Mar 21, 2017 at 10:39:23AM -0400, James Richters wrote:
> I am still having this issue. I've managed to narrow down what is happening
> some. The problem is my data is not actually being written all the way to
> disk. I now have a repeatable proven method to reproduce the issue. Here
I am still having this issue. I've managed to narrow down what is happening
some. The problem is my data is not actually being written all the way to
disk. I now have a repeatable proven method to reproduce the issue. Here
is the sequence.
In my freepascal console application, I create the f
On 17.03.2017 23:51, African Wild Dog wrote:
I will have to redesign my classes =(.
Maybe you just can add a field denoting the thread (by n integer) and
set this when creating an instance, and later just read it for the
appropriate purpose...
-Michael
__
On 17.03.2017 17:13, Karoly Balogh (Charlie/SGR) wrote:
This is actually entirely platform specific. The underlying
implementation of threadvars is very different for each platform, and
highly depends both on the CPU arch and the OS.
That might be true.
Last time I checked (several years ago),
On 17.03.2017 15:57, Reimar Grabowski wrote:
First benchmarks indicate that there isn't much of a performance
increase with the current WebAssembly implementation over pure JS anyway.
A "decent" Framework will compile both to machine code in an "ahead of
time" manner, so simple close loops sho
On 17.03.2017 18:54, Michael Van Canneyt wrote:
Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.
The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in
the IDE
12 matches
Mail list logo
