That main sub is going to thrash the life out of the CPU (100% of one core (at least; possibly more) even when nothing is happening.)
Moving to Tk instead of Win32::GUI to address the OPs problem is a mistake as well.
The one, single advantage of Win32::GUi over the generic GUI frameworks, is that it was designed from the ground up to work in a multi-threaded environment.
The mistake the OP is making is to try handing the responsibility of adding the data to the GUI list back to the event-loop thread. Whilst this is require of Tk and other 'portable' GUI frameworks -- because they are not thread-safe -- it is *NOT* a requirement of Win32::GUI.
He can simple do away with the queue and move the $main_text_window->Append($tmptxt); into the same thread as the data is being gathered and allow the fact that pretty much every Win32::GUI Window function or method is actually implemented internally in terms of SendMessage(). Ie. the data to be append is is queued to the GUIs event loop via the process's system message queue to be processed in a timely fashion.
In reply to Re^2: Win32::GUI window freezing, even with threading. (Wrong solution)
by BrowserUk
in thread Win32::GUI window freezing, even with threading.
by chute
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |