Re: [mingw32] stdin redirection

[Joel Brobecker <brobecker@adacore.com>]

> For a pipe, we use PeekNamedPipe to figure out how many bytes are
> available in the pipe and whether select on the pipe should return.
> For a file, we use the fallback case: we pass the file's HANDLE to
> WaitForMultipleObjects.  What does a file HANDLE do when waited on?
> Maybe it's not the useful behavior.

I see what you mean now. I had a look at the MSDN documentation
for that function: They list the types of handles that can be used, 
and they do not list files. However: They do not list pipes either.
So I'm wondering whether I'm looking at the right thing at all...

    The WaitForMultipleObjects function can specify handles of any of
    the following object types in the lpHandles array:
    
        * Change notification
        * Console input
        * Event
        * Memory resource notification
        * Mutex
        * Process
        * Semaphore
        * Thread
        * Waitable timer

The only information we have at this point is that our experience
seems to show that WaitForMultipleObjects on a file seems to be
working. That is, working unless we did a PeekNamedPipe on its
handle beforehand...

> > If we could find a way to replace the current implementation of
> > fd_is_pipe into something that avoids using any of the pipe functions,
> > then that would probably solve our problem. Unfortunately, despite
> > our intensive search of MSDN, nothing turned up.
> 
> To the best of my knowledge there is no way.

That's what we though too :-(.

> Are you sure that you tested any case in which fd_is_pipe returned
> true?

I just re-verified (see earlier email in that thread).

I had a look at what we were doing in gdb-6.4 (where things worked
for us), and we were actually doing a waitForMultipleObject call
for all handles unconditionally. So it's not so surprising that
Jerome's hack "works", it just reproduces the older behavior...

Your point about WaitForMultipleObjects regarding file handles
seem to suggest that we should be using something else for these
types of handle (I guess just fake a read-available event since
we'll always have something to read until we reach EOF). But the
issue remains the same though: How do we determine that we're
actually dealing with a file handle???

-- 
Joel