[Octave-bug-tracker] [bug #47712] libmng no longer builds under mxe-octave

[Philip Nienhuis]

Follow-up Comment #21, bug #47712 (project octave):

@JWE:
You are certainly right that the case of "A && B" looks like a bug.  
I merely figured the race conditions I saw with zip/gzip (comment #4)
constitute a case of in itself fair user expectations hitting "physical"
limitations, with little to be done about it.
It is the observation that these race conditions happen on the same box in
Linux and in Windows (actually MSYS, based on *nix) that makes me think that
it could be more than a plain bug.

Looking into "A && B" in more detail, all I know and all I can find is that
for "B" to start it is formally sufficient that "A" returns with a success
status.  I have no references as to what "success status" exactly means in
terms of disk I/O.  It's an obvious assumption that in case of an "A && B"
where "B" depends on files made by "A", "B" can immediately access those
files.  In between buffers flushed & files closed and "B" having access to
"A"'s files another step seems to emerge on fast systems.
Note that my own code mentioned in comment #4 invoked zip/gzip executables
through the "system" function with (default) "sync" type. IOW, analogously to
"A && B".

AFAIK "flushing pending writes" and "file handles closed" are userland
concepts; what really happens with the output data being handed through the
operating system to the actual storage device and back is opaque, at least to
me. 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47712>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/