Re: g_io_channel_win32_poll() Problem on Windows

On 7/27/2017 1:51 PM, mualloc . wrote:



// g_io_channel_win32_make _pollfd() documentation says call this





I don't see the documentation in on that function in glib git master.
Also, in glib git master g_io_channel_win32_make_pollfd() just calls g_poll()
after checking that number of FDs is non-zero, although calling g_poll() with
zero FDs is not an error.

As you might guess, in  arv_gv_discover_socket_list_new() function,  GPollFDs
are created and in _discover() function, a broadcast message is sent and then
 polled for reply. but no luck, still in _discover(), it time outs.  By the
way, in Linux, the same application works smootly.
I also checked the discovery packet was actually emitted, and I saw a camera
discovery ack packet coming to my network adapter via WireShark.
Portable I/O is tricky. If i were in your place, i would write the simplest
possible code that does this thing (creates a socket, sends a broadcast
message, then waits for a reply) using W32 socket API only. Once *that* works,
figure out what glib is doing differently. Since you're providing the socket
object to glib, at least socket creation part is already in your hands. IIRC,
glib calls WSACreateEvent() to create an event handle, then binds it to the
socket using WSAEventSelect(), then just waits on the event handle using
conventional WaitForMultipleObjects...() (in your case WaitForSingleObject
would probably be enough). Once it indicates that the event is set, glib calls
WSAEnumNetworkEvents () to see which socket events happened.

Is it possible that the system (and glib) at some point signaled you that the
socket in question can, in fact, be read() from, but you (or glib) ignored
that? In that case WsaEventSelect() won't report FD_READ again, until recv() is

You can also try to run with G_IO_WIN32_DEBUG=1 and see what the output is.

O< ascii ribbon - stop html email! -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]