Hi,
I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows).
The program does essentially this:
opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process
Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows.
To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help.
Teemu
On 1/17/07, Teemu Ikonen tpikonen@gmail.com wrote:
Hi,
I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows).
The program does essentially this:
opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process
Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows.
If you don't wait for the forked process to finish before deleting the file, then you have a bug called a race condition which apparently manifests in wine and not in Windows: you're relying on the forked process to open the file before it gets deleted.
Either wait for the forked process to finish and then delete the file, or have the forked process delete the file.
To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help.
Doesn't closing a file automatically flush it?
Teemu
Damjan
On 1/18/07, Damjan Jovanovic damjan.jov@gmail.com wrote:
On 1/17/07, Teemu Ikonen tpikonen@gmail.com wrote: If you don't wait for the forked process to finish before deleting the file, then you have a bug called a race condition which apparently manifests in wine and not in Windows: you're relying on the forked process to open the file before it gets deleted.
I know and I'm a bit surprised it actually works under windows as well as it does. This program is used extensively under various (modern) versions of windows, and it never fails this way.
I agree this type of code is rather ugly and even incorrect (it's not my code, I just have access to it), but I assume the wine project is aiming for bug-for-bug compatibility with windows? Probably this kind of bug is hard to fix though, as this code relies on the windows scheduler giving the new process a rather large slice of CPU time before returning to the forking process.
Teemu
Teemu Ikonen wrote:
On 1/18/07, Damjan Jovanovic damjan.jov@gmail.com wrote:
On 1/17/07, Teemu Ikonen tpikonen@gmail.com wrote: If you don't wait for the forked process to finish before deleting the file, then you have a bug called a race condition which apparently manifests in wine and not in Windows: you're relying on the forked process to open the file before it gets deleted.
I know and I'm a bit surprised it actually works under windows as well as it does. This program is used extensively under various (modern) versions of windows, and it never fails this way.
Yeah, it might work all of the times you've run it, but it may fail if the box is under very heavy load or different schedulers to the NT one (for example, in Win9x or a new version of Windows).
I agree this type of code is rather ugly and even incorrect (it's not my code, I just have access to it), but I assume the wine project is aiming for bug-for-bug compatibility with windows? Probably this kind of bug is hard to fix though, as this code relies on the windows scheduler giving the new process a rather large slice of CPU time before returning to the forking process.
It's quite easy to hack around - just add a Sleep call in CreateProcessA/W after starting the new program.
-
Damjan Jovanovic -
Robert Shearman -
Teemu Ikonen