[bug #19793] GSFileHandleWin32 readInBackgroundAndNotify problems on multiple pipes

[Matthew Jimenez]

URL:
  <http://savannah.gnu.org/bugs/?19793>

                 Summary: GSFileHandleWin32 readInBackgroundAndNotify
problems on multiple pipes
                 Project: GNUstep
            Submitted by: mjimenez
            Submitted on: Thursday 05/03/2007 at 21:15
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

GNUstep base: 1.12.0 SVN
OS: WinXP SP2
Compiler: Mingw gcc 3.4.2

This occurs on a subversion snapshot at some point after 1.12.0 release
(sorry, I don't recall when). From a quick review of code in gnustep trunk,
this bug appears to still exist.
 
I have some win32 code that calls CreatePipe twice and uses the results for
standard out and standard error on CreateProcess.
The other end for each of the pipes are wrapped using NSFileHandle and call
readInBackgroundAndNotify for first stdout then stderr.

During -[GSFileHandleWin32 watchReadDescriptionForModes:] the object adds
itself as a watcher to the event loop, and the variable "event" is zero
because we are using pipes instead of files or sockets, so it calls [l
addEvent:0 type:ET_TRIGGER watcher:self forMode:....].

This appears to be a problem because for each event, type, & mode, there can
only be one watcher. First stdout, then stderr.
The task will continuously read from stderr and never stdout.

I believe calling [l addEvent:descriptor type:ET_HANDLE watcher:self
forMode:....] will fix the problem, but have not yet tested that. I will
supply a patch file if it does work. 




    _______________________________________________________

Reply to this item at:

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

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