Re: [gnet] Problems with GNet and GIOChannels...

[Tim Müller <tim-mailinglists zen co uk>]

On Friday 20 August 2004 01:46, James Wiggs wrote:

Hi James,

I don't have the slightest clue what exactly goes wrong in your case, but I've 
got some comments nevertheless. 


> 5) The FeedCommand thread
>   - Maintains a TCP socket created using the GNet GTcpSocket API that
>    connects to the hardware data receiver.  Commands/requests are sent
>    via this socket, and explicit reply data is read from it.

Have you tried GConn instead? Not sure if GConn is still marked as 
experimental, but I've made good experiences with it, and the API is _much_ 
simpler than GTcpSocket.


>    Each thread maintains an asynchronous message queue for receiving
> messages from other threads.  The main loop for each thread consists
> of a loop like this (note that I have omitted a lot of debugging/log
> code so that this post isn't even longer):
>
>   -----
> while( 1 ) {
>   maxiter = 10;
>   while( maxiter && (Msg = g_async_queue_try_pop( MyQueue )) ) {
>     /* Handle the message if there is one */
>     maxiter--;
>   }
>
>   maxiter = 10;
>   if( g_main_context_pending( MyContext ) && maxiter ) {
>     /* Deal with callbacks, etc. */
>     g_main_context_iteration( MyContext, FALSE );
>     maxiter--;
>   }
>
>   g_usleep( 1000 );  /* Pause one millisecond, then loop */
> }
>   -----

This looks a bit messed up to me, especially the first 'maxiter' part. Why 
don't you use g_async_queue_timed_pop() instead?

Personally, I'd get rid of the GAsyncQueue stuff altogether though. You have 
your own separate GLib main context for this thread, right? So instead of 
doing g_async_queue_push() in the other threat to send a message to this 
thread, I'd rather do something like:

     GSource *idlesrc;
     idlesrc = g_idle_source_new();
     g_source_set_callback (idlesrc, process_data_func, data, NULL);
     g_source_attach (idlesrc, MyContext);

That way process_data_func() is called with data pretty much as soon as 
possible in the context of MyContext, and you don't have to poll the async 
queue any longer (or do the sleep etc.), but you can just create a main loop 
for MyContext and run it until it is not required any longer.


>   source = g_io_create_watch( SendServerSocketIOC, G_IO_IN );
   ......
>    My problem is that the socket connection SendSocket keeps shutting
> down unexpectedly.  The code will work fine for minutes or even hours,
> but eventually the Forward_Data_Packets stops being able to write to
> the socket and OutputQueue starts filling up with data.  The client
> on the other end of the socket eventually closes its end of the socket
> and tries to reconnect, but gets a "connection refused" error message
> when it does so.  I have branches of logic in the server that are
> supposed to get called when the socket conditions G_IO_ERR, G_IO_HUP
> or G_IO_NVAL come up, which is supposed to close the SendSocket and
> re-register the callback that accepts socket connections, but it
> seems like it never gets called.  

If you have one callback for  G_IO_IN | G_IO_ERR | G_IO_HUP, are you checking 
the conditions bitwise, ie.:

 if ((cond & G_IO_IN))
 {
   ... get data ... and continue below even if you got some ...
 }

 if ((cond & (G_IO_HUP|G_IO_ERR)))
 {
   ... socket closed for some reason ...
 }

?

I found in the past also that the exact details how a closed socket/descriptor 
is communicated varies a bit from system to system. Sometimes I'd get a 
G_IO_IN condition and then foo_read() would return 0 chars as indication of a 
closed socket (well, in that case a pipe). My memory is a little bit murky 
though, so this might just as well be complete rubbish ;)



>    If can post more detailed code samples if necessary, but this note
> is already twice as long as I intended.  Happy to respond to any follow
> up questions!

More useful than 'code samples' would be a minimal test program. Kind of 'run 
this on computer A, run this on computer B, and watch it fail after a while'.

Cheers
 -Tim