Patch for bug 25063 - _pclose should wait for the command processor to terminate and return it's exit status

[Borut Razem]

Attached is the forth attempt for the patch.

On 11/23/2010 03:28 PM, Alexandre Julliard wrote:
 > Borut Razem <borut.razem at siol.net> writes:
 >
 >> > +/* TODO: this shold be same as MSVCRT_MAX_FILES defined in file.c.
 >> > +  The define should be moved to a common header file. Is msvcrt.h 
the right one? */
 >> > +#define MSVCRT_MAX_FILES       2048
 > There's no reason to use this here.

I hope I understood you correcty: I removed the MSVCRT_MAX_FILES 
limitation on fd for popened process (the limit is still in file.c, so 
the popened fd will never be higher then 2047)

I also found out that the fix, proposed by Eric and implemented in my 
previous post:

 > one minor comment:
 > you access file->_file after file has been closed, which can lead to
 > races issues you'd better copy the _file before closing the stream

doesn't solve the race condition in _pclose(). Let suppose that we have 
2 threads:

- thread 1 closes the fd in functon _pclose()
- thread 2 executes _popen(), which reuses the fd, closed by thread 1
- thread 1 waits for the process, belonging to fd, to exit. But since 
the fd was reused by thread 2, thread 1 waits for the wrong process to exit!

That's why I moved fclose() call after waiting for the child process exit.

Borut

---
  dlls/msvcrt/process.c |   89 
+++++++++++++++++++++++++++++++++++++++++++++++-
  1 files changed, 87 insertions(+), 2 deletions(-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Patch-for-bug-25063-_pclose-should-wait-for-the-comm.patch
Type: text/x-patch
Size: 4020 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20101124/083e2177/attachment.bin>