Libpurple disconnecting issue

[Daniel Atallah]

On Wed, Mar 26, 2008 at 6:20 PM, Benjamin Arnaud <bunjeee at free.fr> wrote:
> In fact I just tried the following thing :
>
> replacing wpurple_g_io_channel_win32_new_socket by
> g_io_channel_win32_new_socket and guess what ?
> No more problems.

>
>
> But I suspect that if pidgin is calling its own wpurple_g_io_channel there
> must be a good reason.

You're right :)

> What's the difference between g_io_channel_win32_new_socket and
> wpurple_g_io_channel_win32_new_socket ?

wpurple_g_io_channel_win32_new_socket() is
g_io_channel_win32_new_socket() taken from Glib 2.6.10 (with one
additional bug fix).
The reason this was done was that as of Glib 2.8.0, there is a new
win32 GIOChannel socket implementation that doesn't work in some cases
that the old one did (the old one has its own issues, but is fine for
what we need it for).

If g_io_channel_win32_new_socket() does work correctly for you (i.e.
you can connect to MSN and don't experience connectivity issues), then
that is fine to use, but I suspect that what you're seeing here is
indicative of other problems.

> As for the threads : I have a PurpleApi thread class with appropriate slots,
> and I'm receving signals from my GUI.
> Since every single GUI threaded signal is connected to that threaded object,
> that shouldn't be an issue.

I have a suspicion that Ethan is right in that your synchronization is
the issue here.

The differences in the GIOChannel implemenations may explain why a
synchronization problem is less obvious with the "new" one. The "old"
one (wpurple_g_io_channel_win32_new_socket) is quite ugly; it uses a
thread per socket to read all data as it comes in and then trigger the
various iochannel events based on what has been read.  The new one
uses WSAEventSelect() to leverate the native win32 socket event stuff.

-D