Re: Windows g_socket_create_source problem

[Daan Nusman <d nusman re-lion com>]

Hi Tor,

thanks for your speedy reply.

Tor Lillqvist wrote:
> > I think I am on the right track: I'm creating a Lua Socket, getting the file
> > descriptor (which is a normal fd/SOCKET), create a new GSocket using
> > g_socket_create_source, and attaching a callback that should fire on data
> > available on the socket.
> >     
>
> Please note that the GSocket API is quite new, and it is possible you
> are the first person to ever try it seriously on Windows. Problems are
> to be expected. Then throw in a weird language biinding in the mix
> (which might, or might not, be partly to blame), and the number of
> people able to help you goes way down. You should file a bug, and
> attach a *minimal* but *complete* free-standing sample program in
> plain C (i.e. no Lua stuff).
>   
I've followed your advice, and in the process created a test app that 
can run using both native GSocket sockets and low-level sockets. The 
GSocket sockets work! However the low-level sockets (and, by extension, 
all sockets from other socket libraries) do not. I have a feeling that 
this is because of the

win32_unset_event_mask (socket, FD_READ);

call in g_socket_receive() in gsocket.c(1651).

However, I cannot call that function from my own code because it is 
private to GSocket. Windows itself automatically resets the associated 
windows event handle selected with WSAEventSelect when recv is called, 
so that should not be the problem.

A solution might be to clear those GSocket flags after the callback has 
returned instead of the g_socket_receive function?

For now, I think I will just use the GSocket recv and pass that data on 
to Lua, instead of having Lua do the recv call.


Anyway, the test app can be found here:  
http://matrix.re-lion.com/temp/main.cpp
It waits for UDP messages on port 26632. I've only tested/ran it under 
Windows. It has these options:

#define USE_GSOCKET_FOR_RECV      0
#define USE_GSOCKET_NEW           1
// setting USE_GSOCKET_FOR_RECV to 0 and USE_GSOCKET_NEW to 1 causes a 
low-level recv() to be used on a GSocket (does not work)
// setting USE_GSOCKET_FOR_RECV to 1 and USE_GSOCKET_NEW to 0 causes a 
g_socket_new_from_fd to be created and a g_socket_receive for receiving 
(works!)
// setting USE_GSOCKET_FOR_RECV to 0 and USE_GSOCKET_NEW to 0 causes a 
g_socket_new_from_fd to be created and low-level recv(does not work) 
(this would be the main case for using other socket libs)
// setting USE_GSOCKET_FOR_RECV to 1 and USE_GSOCKET_NEW to 1 results in 
an all-GLib socket implementation (works)

Presumably, all combinations do work under Linux?
The output for the non-working cases is:
--------------
Send a UDP message to localhost:26632 or do a UDP broadcast...
callback! condition: 1. got data: 114 bytes: FEAR ME FOR I AM A UDP PACKET
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
callback! condition: 1. WSA error: 10035
...etc
--------------
(WSA error 10035 is WSAEWOULDBLOCK)

> P.S. Does the gtk-win32-list still exist? I thought the consensus was
> that it is unnecessary and can be dropped.
>
>   
No idea, it's still there on the site 
(http://mail.gnome.org/mailman/listinfo/gtk-win32-list) though. I'll 
just remove it from the Cc list then.

Thanks for your time,
Daan