Bug #81

avatar

closing server tabs will freeze the frontend [win32]

Added by Lycaon - 5971 days ago. Updated 5217 days ago.

Status:Closed Start:
Priority:Urgent Due date:
Assigned to:avatarMirco Bauer % Done:

100%

Category:Frontend GNOME
Target version:0.8
Complexity:

Found in Version:

Votes: 0

Description

This problem only occurs within Windows using the GTK# frontend. When closing a servertab, and smuxi warns you that it will also close all channels and chats, it will freeze smuxi totally. In first i thought the whole program was dead, but i decided to leave it on and after a feq MINUTES it actually closed all tabs and i could continue using smuxi.

I don't know if it occurs because of the missing gconf2.exe (wich we had a talk about in irc) or just because of GTK#, or your code. Nor did i find out if it's the engine or just the frontend.

Associated revisions

Revision 76d75b0c54c840a4809f2505495c917e5ebe3170
Added by Mirco Bauer 5217 days ago

Close networks in background as it might block and with that the UI becomes unresponsive. (closes: #81)

History

Updated by Mirco Bauer 5971 days ago

avatar

Hm, migh be related to thread handling, need to debug that on windows then.

Updated by Lycaon - 5971 days ago

avatar

I've tested further within windows, i cannot establish a connection via the Quick Connect options to whatever server i choose, after i closed a server tab. Now i have to restart smuxi again. So indeed this would be very critical for windows users.

Updated by Mirco Bauer 5946 days ago

avatar

Zhila please try to reproduce this bug and report back.

Updated by Mirco Bauer 5944 days ago

avatar

So Zhila found it, it's freezing the GUI for around 45 seconds.. it doesnt always happen though. I expect it's either server specific (how they handle QUIT and sockets) or just a race condition in the threading of SmartIrc4net. I will postpone this to 0.6.3 or 0.7.0 for now though.

Updated by Mirco Bauer 5224 days ago

avatar
10:08:30 <sorear> Thread.Abort says it has no effect unless the target is executing managed code
10:09:08 <meebey> hm, that is interesting!
10:09:35 <meebey> that could be the reason why Smuxi blocks on windows when disconnecting from a server
10:09:40 <meebey> while on linux with mono it doesn't
10:09:59 <meebey> I dont think that limitation applies to mono's threading implementating, but I am not sure
10:11:05 <meebey> it usually blocks for exactly 30 seconds ;)
10:11:22 <sorear> Thread.Interrupt, meanwhile, can interrupt thread synchronization primitives, but not I/O or managed code execution

So could be the cause of the issue, Mono probably doesn't have that limitation. A workaround would be to disconnect using a background thread.

Updated by Mirco Bauer 5224 days ago

avatar
  • Assigned to changed from Jeffrey M Richardson to Mirco Bauer

Updated by Mirco Bauer 5217 days ago

avatar
  • Status changed from New to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF