(Sending to a broader list, in case anybody has answers.)
On Jun 26, 2017, at 10:53 AM, Stig Bjørlykke <[email protected]> wrote:
> The extcap interface toolbar is not supported on Windows yet,
> basically because I don't know how the pipe handling is done when
> using select(),
Sadly, Windows' handling of "wait for something to happen" is a bit clumsier
than UN*X's.
UN*Xes have select() and poll(), with the possible addition of some other
similar mechanisms such as Linux's epoll() or *BSD/Darwin's kqueues. You can
wait for a device, a socket, or a pipe with them. (Sadly, in the general case,
you can't wait for a process or thread to terminate with select(), although you
can do it with kqueues on at least some platforms. I'm not sure whether the
inability to wait for a mutex to unlock or a condition variable to be signaled
is a significant issue or not.)
Windows has select()
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx
which works on sockets, sockets, sockets, and sockets, and
WaitForMultipleObjects():
https://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx
which works on a number of things - only one of which is the equivalent of a
readable file descriptor, namely "console input". It doesn't appear that you
can use a HANDLE for a pipe (named or unnamed), and, while Microsoft seem to
indicate that you can do regular ReadFile()/WriteFile() I/O on a socket:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740522(v=vs.85).aspx
they don't indicate what the connection is between a socket descriptor and a
socket handle (they have the same size, 32 bits in Win32 and 64 bits in Win64,
but are SOCKET values usable as HANDLEs, or is there a "get a handle for this
socket descriptor" call?) - and even if you get a HANDLE it probably works no
better with WaitForMultipleEvents() than do pipe HANDLEs.
For named pipes, you can use "overlapped mode" for asynchronous I/O:
https://msdn.microsoft.com/en-us/library/aa365788(VS.85).aspx
and can create an event handle that's signaled when a read or write completes,
and hand *that* to WaitForMultipleObjects(). This appears, from some Web
searching, to be the closest thing to waiting for a read to be possible, but it
would be done differently - instead of
select();
if (pipe is readable) {
read into buffer;
process that data if we can;
}
it'd be more like
start an asynchronous read into the buffer;
WaitForMultipleObjects();
if (event for that pipe was triggered) {
process the data that was read if we can;
}
Anonymous pipes are just named pipes with created unique names:
https://msdn.microsoft.com/en-us/library/aa365141(v=vs.85).aspx
but, as that page says, "Asynchronous (overlapped) read and write operations
are not supported by anonymous pipes.".
For sockets, it appears you can do an operation that's similar to select(),
but, instead of waiting, returns an event handle:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms741576(v=vs.85).aspx
However, those event handles may, or may not, be like regular Windows event
handles; they are documented as working with WSAWaitForMultipleEvents() rather
than with WaitForMultipleObjects():
https://msdn.microsoft.com/en-us/library/windows/desktop/ms742219(v=vs.85).aspx
and they also don't indicate whether you can use regular event objects with
WSAWaitForMultipleEvents().
Furthermore, GUI applications should probably use MsgWaitForMultipleObjects().
I think that's what's used in the GUI event loops of GTK+ and Qt on Windows.
So doing the equivalent of select()/poll() on Windows appears to be a challenge.
If anybody has more information than what I found, that'd be helpful.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
