Playing with threads (Read 1778 times)

Started by Nightwish, October 30, 2004, 22:50:12

0 Members and 1 Guest are viewing this.
Playing with threads |
October 30, 2004, 22:50:12

Note, that this is highly experimental and may cause unexpected problems...

The message log streaming code has become quite complex in tabSRMM. Lots of new features like the background colors, dividers, grid lines and a new (but slower, because of OLE) message icon code added a lot of code and made streaming the events into the Rich Edit control slower than in standard SRMM.

Opening multiple tabs at once (for example, if you log into 3 accounts and have lots of messages waiting) could easily freeze the main thread for a few seconds. Bad thing... Really bad.

So what to do?

I played around and decided to implement an experimental feature to avoid a blocking main thread. It uses a separate thread to collect and dispatch the streaming events, so the main thread will never be frozen whenever a large amounts of text is written to the log of a message session. There is a queue with room for 100 streaming events (you really should never reach this, even if 100 buddys are spamming you at the same time) which is constantly being watched by the streaming thread (actually, the thread doesn't watch the queue actively, but rather receives a notification when there is something to do).

There shouldn't be any visisble changes, except that the initial log seems to appear delayed, but this is only a visual effect, because the new code makes the creation of the tab/window a lot faster (the old code had to wait until the streaming process was finished, which could cause an empty and unresponsive message window.
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork