This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Support Windows in event-loop.c


Mark Mitchell <mark@codesourcery.com> writes:

> Now, assuming I can do this, do y'all want me to try to put this in
> libiberty, or in GDB itself?

I suspect that a select which can works on Windows named pipes can
only be implemented in conjunction with an I/O library for reading
from the pipes.  This is because to make select work properly, the
thread which is responsible for the pipe has to actually read some
data from the pipe.  At least the last time I looked, there is no way
to wait for a pipe to have some data available.  There is a
PeekNamedPipe (I think) call which can check whether there is data
available, but the only way to use that is to busy wait.  So that
means that the thread will have read some data which the main program
wants.  And the only reasonable way I see to handle that is to provide
an interface to read from the descriptor which will check whether any
data was read by the read.

In other words, you need not just a select emulation, but also a read
emulation, and the two have to work together.  And really to make that
work reasonably, you will need to emulate open, close and write also.
And that we get into socket and pipe.

So that is crazy.  We don't want to emulate select.  I think it would
make more sense to add an argument to add_file_handler which indicates
the type of the file descriptor.  Then split up event-loop.c into
generic code, Unix specific code, and Windows specific code.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]