<div dir="ltr"><div dir="ltr">Andres,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 10:32 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phil,<br> <br> Regarding your observations on forceChangesToDisk, first a side comment. <br> That there is a method or even a primitive called <br> 'blah-blah-flush-blah' does not mean the function fflush()<br> <br> <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html" rel="noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html</a><br> <br> or equivalent is actually called.</blockquote><div><br></div><div>Good point. Just because it seems logical that's what it would/should be doing doesn't constitute proof. So let's start with a sanity check:</div><div><br></div><div>Running a recent 64-bit spur image on Linux, I apply updates to get to 3878, fire up the image and open a Workspace in which I run in sequence:</div><div><br></div><div>f:='flushtest.txt' asFileEntry .<br>ws:=f writeStream. "this gets us a 0 byte file"</div><div>ws class. "StandardFileStream"<br>ws nextPutAll: 'this is a test'. "still 0 bytes... it's in the buffer as expected"<br>ws flush. "14-byte file and the contents are as expected... looks good"<br></div><div><br></div><div>I feel better: flush is flushing... now let's look at how.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Assuming otherwise eventually leads <br> to conclusions such as "xyzOS is so broken haha", and that's really self <br> limiting.<br></blockquote><div><br></div><div></div><div>Fair enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> So, with a skeptic mentality in place, what is that flush method <br> actually doing?</blockquote><div><br></div><div>Taking a half step back, I ask the question: what's it supposed to be doing? According to <a href="https://github.com/Geal/Squeak-VM/blob/master/platforms/Mac%20OS/vm/Documentation/3.2.2%20Release%20Notes.rtf" target="_blank">https://github.com/Geal/Squeak-VM/blob/master/platforms/Mac%20OS/vm/Documentation/3.2.2%20Release%20Notes.rtf</a> the file flush primitive was added in (classic) VM 3.0.5 and 'now actually flushes the file via an OS call' as of 3.0.6. So that gives an indication that it at least *should* correspond to something at the OS level rather than a home grown approximation of flush. OK, back to our regularly scheduled programming...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> It looks like the relevant code is this:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> primFlush: id<br> "Flush pending changes to the disk"<br> | p |<br> <primitive: 'primitiveFileFlush' module: 'FilePlugin'><br> "In some OS's seeking to 0 and back will do a flush"<br> p _ self position.<br> self position: 0; position: p</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> That primitive failure is strange indeed, plus the failure is silent so <br> good luck noticing something might be off. So, rather than seeking back <br> and forth to (pretend to) deal with the failure, the question should be <br> why fflush() can't do its job.</blockquote><div><br></div><div>Intrigued, I proceed to open a VMMaker image...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Does primitiveFileFlush actually call <br> the equivalent of fflush() in all platforms?</blockquote><div><br></div><div>When I look at FilePlugin>>primitiveFileFlush it calls sqFileFlush: with the file as a parameter. Just one problem: the only implementor I can find is FileSimulatorPlugin which in turn just sends #flush which gets us right back to #primitiveFileFlush (and besides we're not running in the simulator so this isn't applicable) Not finding anything else interesting in the image, I grep the VM source tree and find sqFileFlush in:</div><div>platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c (which calls fflush(getFile(f)) and has an interesting comment[1])</div><div>platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c (which calls FlushFileBuffers(FILE_HANDLE(f)) and ignores the return code)</div><div> </div><div>[1] "fflush() can fail for the same reasons write() can so errors must be checked but sqFileFlush() must support being called on readonly files for historical reasons so EBADF is ignored"... so there's one example of how it could fail but for this particular failure case it is ignored in the C code</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Where and why does the <br> primitive fail, exactly?</blockquote><div><br></div><div>It looks like it will never fail on Windows (regardless of the fact that the call might have) but can fail everywhere else depending on the rules of the particular OS. On Linux, over a dozen possible error codes are given (one of them is the ignored EBADF case) as well as a note that a variety of additional errors can occur depending on the particular object the file descriptor represents. So reasons: many.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Suppose the id is stale, why does changing the <br> file position improve the situation on an file that is not open? Does <br> the primitive fail because it's not implemented? If that happens, then <br> why isn't the hack of opening / closing the file done here instead, <br> i.e.: why is there yet another hack that is different?</blockquote><div><br></div><div>Good questions and I could only speculate as to the answers.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Or, why was it <br> necessary to hack forceChangesToDisk, in a different way, on top of the <br> hack here?</blockquote><div><br></div><div>I believe the #forceChangesToDisk hack had a different objective. The other hack(s) are dealing with flush failure, #forceChangesToDisk appears to predate flush support and/or to deal with the reality at the time that flush alone often wasn't a complete solution.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Exactly what operating systems are those "some OS's" the <br> comment talks about?</blockquote><div><br></div><div>I'm as baffled by that cryptic comment as you. I did a quick search on the text of the comment and found <a href="http://forum.world.st/The-Inbox-Files-monty-172-mcz-td4950635.html" target="_blank">http://forum.world.st/The-Inbox-Files-monty-172-mcz-td4950635.html</a> which seems to agree that there's a problem in silently ignoring the error.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Is there any evidence in support of the <br> authoritative assertion that seeking causes flushing?<br></blockquote><div><br></div><div>I did a little more general search trying to find something, anything that might point in a direction that leads to clarity... nothing so far.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Andres.<br> -- <br> Cuis-dev mailing list<br> <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>