Re: g_io_channel_win32_poll() Problem on Windows

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

 



On 7/27/2017 1:51 PM, mualloc . wrote:
> arv_gv_discover_socket_list_send_discover_packet(socket_list);
> 
> 
> do{
> 
> #ifdef_WIN32
> 
> // g_io_channel_win32_make _pollfd() documentation says call this
> 
> if(g_io_channel_win32_poll(socket_list->poll_fds,socket_list->n_sockets,ARV_GV_INTERFACE_DISCOVERY_TIMEOUT_MS)==0)
> 
> 
> #else
> 
> if(g_poll(socket_list->poll_fds,socket_list->n_sockets,ARV_GV_INTERFACE_DISCOVERY_TIMEOUT_MS)==0)
> 
> #endif
> 

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
called.

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

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list




[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux