Hi Piotr, Hi all,
I traced down this commit as the origin of the regression, where I cannot parse stdout of wine correctly anymore. See also https://bugs.winehq.org/show_bug.cgi?id=37345
I hope, sombody knowledgable (Piotr maybe you as the author) could help me figure this out or even provide a fix...
Description: When calling wine from another process after redirecting stdout to a pipe, wine does not flush the stdout-buffer correctly anymore (Wine 1.6 did correctly).
Attached is a usecase. To test do: i686-w64-mingw32-gcc helloworld.c gcc callwine.c ./a.out
What will happen is: - on a buggy wine it will take 10 seconds and then all of the stdout-buffer is flushed on the exit of the child. (imagine the child would run longer than the 10 seconds) - on a good wine we will see some stdout-content then 10 second sleep and then the rest of the content.
This is a regression that happened between 1.7.4 and 1.7.5. The bisect identified commit afec0b00bd6250fe21e8deccbc8116a4aca6a7a4 "msvcrt: Make the first call to fwrite buffered." as problem.
The attached patch is a revert of this commit ported forward to 1.7.27. Unfortunately I don't quite grasp the logics of the offending commit. If somebody who knows that patch could help, I'd highly appreciate it.
Cheers, Andreas
Hi,
On 10/02/14 10:28, Andreas Fuchs wrote:
Hi Piotr, Hi all,
I traced down this commit as the origin of the regression, where I cannot parse stdout of wine correctly anymore. See also https://bugs.winehq.org/show_bug.cgi?id=37345
I hope, sombody knowledgable (Piotr maybe you as the author) could help me figure this out or even provide a fix...
Description: When calling wine from another process after redirecting stdout to a pipe, wine does not flush the stdout-buffer correctly anymore (Wine 1.6 did correctly).
Attached is a usecase. To test do: i686-w64-mingw32-gcc helloworld.c gcc callwine.c ./a.out
What will happen is:
- on a buggy wine it will take 10 seconds and then all of the stdout-buffer is flushed on the exit of the child. (imagine the child would run longer than the 10 seconds)
- on a good wine we will see some stdout-content then 10 second sleep and then the rest of the content.
this is not a bug. The pipes are supposed to be buffered on windows.
The simple way of reproducing it is following: i686-w64-mingw32-gcc helloworld.c wine a.exe |more (linux) a.exe |more (windows) In both cases you will see all of the output after 10 seconds.
Cheers, Piotr
Hi Piotr,
thanks for clearing this up for me... I was caught so off guard by the change in behavior that it did not occur to me that this was actually a correction...
Sorry for the trouble...
Cheers, Andreas
Am Donnerstag, den 02.10.2014, 11:01 +0200 schrieb Piotr Caban:
Hi,
On 10/02/14 10:28, Andreas Fuchs wrote:
Hi Piotr, Hi all,
I traced down this commit as the origin of the regression, where I cannot parse stdout of wine correctly anymore. See also https://bugs.winehq.org/show_bug.cgi?id=37345
I hope, sombody knowledgable (Piotr maybe you as the author) could help me figure this out or even provide a fix...
Description: When calling wine from another process after redirecting stdout to a pipe, wine does not flush the stdout-buffer correctly anymore (Wine 1.6 did correctly).
Attached is a usecase. To test do: i686-w64-mingw32-gcc helloworld.c gcc callwine.c ./a.out
What will happen is:
- on a buggy wine it will take 10 seconds and then all of the stdout-buffer is flushed on the exit of the child. (imagine the child would run longer than the 10 seconds)
- on a good wine we will see some stdout-content then 10 second sleep and then the rest of the content.
this is not a bug. The pipes are supposed to be buffered on windows.
The simple way of reproducing it is following: i686-w64-mingw32-gcc helloworld.c wine a.exe |more (linux) a.exe |more (windows) In both cases you will see all of the output after 10 seconds.
Cheers, Piotr
-
Andreas Fuchs -
Andreas Fuchs -
Piotr Caban