Libpurple disconnecting issue

[Benjamin Arnaud]

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.
What's the difference between g_io_channel_win32_new_socket and 
wpurple_g_io_channel_win32_new_socket ?

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.


----- Original Message ----- 
From: "Evan Schoenberg" <evan.s at dreskin.net>
To: "Benjamin Arnaud" <bunjeee at free.fr>
Cc: <devel at pidgin.im>
Sent: Wednesday, March 26, 2008 10:57 PM
Subject: Re: Libpurple disconnecting issue


>
> On Mar 26, 2008, at 5:42 PM, Ethan Blanton wrote:
>
>> Benjamin Arnaud spake unto us the following wisdom:
>>> I have two main threads :
>>> - my Qt interface.
>>> - Libpurple's thread.
>>>
>>> libpurple is running on its own thread with its own 
>>> "g_main_loop_run(loop);"
>>>
>>> The only interaction between both sides are signal based, according  to
>>> Qt's doc those are Thread safe.
>>
>> What do you mean, "those are Thread safe"?  How does libpurple receive
>> those signals?
>>
>> (I suspect this is, in fact, your problem.)
>
> Ah, good catch, Ethan. I skipped over that line apparently.  "Thread 
> safe" doesn't necessarily mean that they are being received on the 
> desired thread.  You should verify that signals coming from Qt for use  by 
> libpurple (whatever that may mean) are being processed on the  libpurple 
> thread.  You can not access libpurple under any circumstance  (including 
> access data structures managed by libpurple) from the Qt  thread with 
> assurance of safety.
>
> -Evan
>