Bug #81
closing server tabs will freeze the frontend [win32]
| Status: | Closed | Start: | ||
| Priority: | Urgent | Due date: | ||
| Assigned to: |  Mirco 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
Close networks in background as it might block and with that the UI becomes unresponsive. (closes: #81)
History
Updated by Mirco Bauer 5998 days ago
Hm, migh be related to thread handling, need to debug that on windows then.
Updated by Lycaon - 5998 days ago
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 5971 days ago
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 5251 days ago
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 5244 days ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset 76d75b0c54c840a4809f2505495c917e5ebe3170.