pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] 0.14 - attempted fix of the "freeze when connection is l


From: Charles Kerr
Subject: Re: [Pan-users] 0.14 - attempted fix of the "freeze when connection is lost"
Date: Tue, 13 May 2003 15:02:56 -0700
User-agent: Mutt/1.5.4i

On Tue, May 13, 2003 at 10:08:56PM +0200, Alberto BARSELLA wrote:
> Hi,
> 
> On Tue, 13 May 2003 at 07:43:07AM -0700, Charles Kerr wrote:
> 
> >I made a couple of tweaks -- I changed the variables to make explicit
> >the `consecutive' nature of the count, and added a log message after
> >Pan gives up and dumps a socket after too many EAGAIN messages --
> >but the patch should be the same as yours in all ways that count.
> 
> Including a possible segfault, I fear.
> In the socket constructor, the call to g_io_channel_set_flags, I'm not
> sure that passing a NULL for the GError** is safe (the glib
> documentation does not say that it's acceptable).

It is acceptable; see giochannel.c's entry assertions.

> I've made the following modification to that piece of code (look in
> pan_socket_constructor).
> The idea is to add a return pointer for the error when the NONBLOCK flag
> is set, but I don't know exactly how to report an error in the case it
> fails.  I've set the error flag to true, but is this acceptable in the
> constructor?
> 
>       else {
>               GError* err = NULL;
>               sock->gio_channel = 
>               gnet_tcp_socket_get_iochannel(sock->gnet_socket);
>               if (g_io_channel_get_encoding (sock->gio_channel) != NULL)
>                       g_io_channel_set_encoding (sock->gio_channel, NULL, 
>                       NULL);
>               g_io_channel_set_buffered (sock->gio_channel, TRUE);
>               g_io_channel_set_line_term (sock->gio_channel, "\n", 1);
> 
>               g_io_channel_set_flags(sock->gio_channel, 
>               G_IO_FLAG_NONBLOCK, &err);
>               if (err) {
>                       log_add_va (LOG_ERROR, _("Error setting NONBLOCK for 
>                       %p: %s"), sock, err->message);
>                       g_error_free (err);
>                       pan_socket_set_error_flag (sock, TRUE);
>                       return;
>               }
> 
>               log_add_va (LOG_INFO, _("New connection %p for %s, port 
>               %d"), sock, server_address, port);
>       }

Pan's gone a long time without setting nonblock, so it's not the end
of the world if g_io_channel_set_flags() fails.  So rather than 
rearranging the function calls so that _set_flags() comes at the end,
it's just as good to not worry about _set_flags() failing.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]