Do you mean to say you pass something other than window/screen updates as
messages? Cos in my experience if the parent thread is in Dialog() it
dosent
need to be woken up for updates to the screen.
We may be getting wires cross slightly - my poor explanation no doubt:)
When a thread is blocking on Dialog() windows does send it messages to
redraw the screen, most of these messages are handled by win32-gui
internally. With Rob's code, you can send items to the thread blocking on
Dialog(), which will then wake it up and process the event in that thread.
Yes of course it makes sense. What I've noticed is that threads are still
more memory and cpu consuming than normal "quescient" processes. I had a
bad
experience with socks server on a DEC alpha machine with threads that
finally I had to recode everything to be single threaded. Unless youre
writing something like apache you probably wouldnt need to be so worried
about memory and cpu. And unless you want to provide a usable interface to
the Perl POE framework. If its not too much work, and thats a very big if,
then the single threaded option could be left in :)
Yeah, thread programming is a right pain:) Part of the reason for Rob's code
is to make it very simple to build threaded win32-gui apps - win32-gui
should take on the pain so to speak, rather than the programmer.
In the case of Perl, it is expensive in memory to have lots of threads -
although with later versions it should become less. Performance in general
shouldn't suffer.
Cheers,
jez.
