Hi Tim, Hi Tim,

    TIM R, I finally looked at the plugin code and the primitive has been
there since it was contributed by "monty" in September of 2015.

It's called primitiveFileSync; use as you would for primitiveFileFlush.  So
no need to change the VM, but it would be easy to implement such that a
command line argument made sqFileFlush call swFileSync.

Tim F, I note that in platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
sqFileFlush is already implemented as sqFileSync.  Isn't this an error?
Shouldn't we remove the call and simply make sqFileFlush empty on win32?

On Sat, May 21, 2016 at 11:44 AM, tim Rowledge <tim at rowledge.org> wrote:

>
> > On 21-05-2016, at 11:02 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> > Well, the case is that it /is/ a performance issue.  Writing to disc is
> way more expensive than flushing to kernel buffers.  How about saying what
> you think about my c) and d) options?  That's a way of avoiding the
> performance issue and solving the kids-are-humans issue.
>
> Either would be just fine by me, no problem. Adding a new prim might be
> even better since it would defer control up to the image, which always
> seems the best option to me. However, opening the can of rancid worms that
> is the file system interface doesn’t appeal too much right now. I think for
> simplicity and testing I’ll stick with a #define and we can revisit it
> later if it seems to solve any realworld problems.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Got into the gene pool while the lifeguard wasn't
> watching.
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160523/3e0b00b0/attachment.htm