[Pidgin] #7849: Pidgin hangs up on exit

[Pidgin]

#7849: Pidgin hangs up on exit
------------------------------------------------------------------+---------
 Reporter:  Hannes Rannes                                         |        Owner:  datallah       
     Type:  defect                                                |       Status:  new            
Milestone:                                                        |    Component:  winpidgin (gtk)
  Version:  2.5.3                                                 |   Resolution:                 
 Keywords:  windows vista, exit, hang up, freeze, not responding  |  
------------------------------------------------------------------+---------

Comment(by darkrain42):

 This problem is caused by the Network Location Awareness thread, since
 WSANPIoctl() waiting for a network state change and apparently
 WSACleanup() waits for the ioctl to return before cleaning up. That
 function is triggered initially '''30 seconds''' after the first
 initialization of Pidgin, which is why Pidgin can exit properly in the
 first 30 seconds of execution. I have NFI why this magically broke in
 2.5.3; having looked at a diff of 2.5.2 to 2.5.3, I see no reason it
 should break all-of-a-sudden.

 The attached patch fixes this issue for me, though to anyone who likes
 threads and mutexes, please review my logic. The mutex protects
 network_change_handle and network_init. I moved the 30s second wait to
 happen while the handle is not initialized (it probably doesn't
 matter/that may not be the right thing to do, but I figured it was better
 to sleep while the handle is NULL).

 Additionally, GStaticMutex apparently throws "warning: dereferencing type-
 punned pointer will break strict-aliasing rules" during compilation. See
 [http://bugzilla.gnome.org/show_bug.cgi?id=316221 GTK bug #316221]. I
 believe using GMutex would not throw this warning, but would ideally
 require a g_thread_join(nla_thread) + g_mutex_free() in order to fully
 clean up the mutex (for GUIs that uninit+init libpurple in the same
 execution cycle). And that would possibly delay the uninit by 30s.

 Also, disabling the NLA service doesn't fix this, which makes me wonder
 about the WSALookupServiceBegin()...

-- 
Ticket URL: <http://developer.pidgin.im/ticket/7849#comment:42>
Pidgin <http://pidgin.im>
Pidgin