Hi Dave,


> With respect to VM changes, there is very little chance that the
> VM (FilePlugin actually) has changed recently. But is it certainly
> possible that the compilers and runtime libraries have changed over
> the last year or so, and it is possible that the actual runtime
> behavior of fflush() will be different as a result. If so, I would
> not regard that as a VM problem per se, it is really going be a
> difference in the runtime environment.
>

I do hope you're right, but when you say, the "runtime environment", do you
mean statically-linked stuff?   Because, in terms of the dynamic linkages,
the test is running both times in the same environment.  If I use the old
VM, it works.  If I use the new VM, I have to change #flush or it won't
work.

 - Chris


>
> As a point of comparison, I find that my CommandShell has accumulated
> a few bugs over the years as a result of differences in the runtime
> environments on Linux and other Unix systems. Some of these I have
> addressed, and some I haven't. But it is not a defect in the VM, more
> likely it is some poor assumptions in my original implementation that
> became visible as the runtime C library changed.
>
> HTH,
> Dave
>
>
> On Mon, Jan 13, 2020 at 01:15:15AM +0100, Levente Uzonyi wrote:
> > Hi Chris,
> >
> > Do you expect #flush to write the changes to disk?
> >
> > Levente
> >
> > On Sun, 12 Jan 2020, Chris Muller wrote:
> >
> > >Magma has been stable in 5.2 for a long time under an older VM, all
> tests
> > >pass.?? But by changing ONLY the VM (not the image) to the new
> > >release-candidate, it fails the forward-recovery test.?? This test
> tests
> > >the scenario of a
> > >server failure during mid-write.?? Unless I change
> > >StandardFileStream>>#flush as in Files-cmm.182,??the recovery data
> which
> > >Magma relies on #flush to ensure is preserved is, in fact, not
> > >preserved.?? It appears to be a breakage
> > >of the contract which causes the test to fail.?? This functionality is
> > >important to avoid corrupting databases.
> > >I saw a discussion on the Cuis list in which someone was asserting that
> > >flush is no longer necessary(!!), and made a vague reference to a
> "thread
> > >on squeak-dev" which I never found.
> > >
> > >I hope this is just an oversight, otherwise I'll have to rely something
> > >like Files-cmm.182, which is half the speed of the old #flush.
> > >
> > >Best,
> > >?? Chris
> > >
> > >
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200113/412f3814/attachment.html>