Libpurple disconnecting issue

[Benjamin Arnaud]

Hi Evan,

Thanks for the answer

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.

My crashes are random they don't occur everytime...

Last but not least I'm encountering that disconnecting issue only when using "wpurple_g_io_channel_win32_new_socket"
Maybe I missed some kind of win32 specific init or something because pidgin works using that call on win32.

Beside calling "wpurple_g_io_channel_win32_new_socket", is there anything else I'm supposed to do to ensure win32 compatibility?
  ----- Original Message ----- 
  From: Evan Schoenberg 
  To: Benjamin Arnaud 
  Cc: devel at pidgin.im 
  Sent: Wednesday, March 26, 2008 8:31 PM
  Subject: Re: Libpurple disconnecting issue




  On Mar 26, 2008, at 11:45 AM, Benjamin Arnaud wrote:


    I'm developping a threaded Qt windows client. I have a full thread to run Libpurple in its own GLIB loop environment.


    It's running on windows I have this line in my event input add:
    #ifdef _WIN32

    channel = wpurple_g_io_channel_win32_new_socket(fd);



    Unfortunately it appears that when calling "purple_account_disconnect" I get random crashes :

    the only output I have is :

    (client.exe:352): GLib-CRITICAL ** : g_hash_table_destroy: assertion `hash_table->ref_count > 0' failed.

    (I get this line FOUR times).

    When calling "g_io_channel_unix_new" instead of "wpurple_g_io_channel_win32_new_socket" the error disappears.



    Has anyone encountered the same thing ? Can it be an issue with threading ? Could I contribute to solve this ?



  libpurple should be able to run on a thread, but it is vital that you ensure that *all* messages to libpurple are sent on that thread, as libpurple is not safe for interthread interactions.  Are you managing the glib run loop such that it iterates on your libpurple thread?


  Are you sure you really need to run libpurple and glib on a thread in any case?  A lot of effort has gone into ensuring that libpurple acts in a non-blocking fashion for networking operations and most time-consuming calls.


  -Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080326/528ea3b6/attachment.html>