Re: Waiting for something to happen on a pipe/socket on Windows

[Roland Knall <rknall () gmail com>]

This is one of the best and most comprehensive explanations for Windows
sockets I read so far.

@Stig - You could take a look at extcap_spawn.c, there you will find code,
also in extcap.c for implementing waiting on that thing, Windows likes to
call a "Named Pipe"

cheers,
Roland

On Tue, Jun 27, 2017 at 10:59 PM, Guy Harris <guy () alum mit edu> wrote:

> (Sending to a broader list, in case anybody has answers.)
>
> On Jun 26, 2017, at 10:53 AM, Stig Bjørlykke <stig () bjorlykke org> 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 <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=
> unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe