> The problem is how to do send messages back to the parent thread if it is > Dialog - it has to be "woken" up by a message from the windows queue - > which > is what happens in 3 above. >
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. > It is legal to use windows handles across threads, so you could for > example, > pass window/control handles to worker threads and let the worker do > various > updates. The problem with this approach is that you'll probably need to > synchronise access to these handles. As soon as you start adding that kind > of logic, it's often much easier to use thread queues, with one thread > (the > boss usually) to update the UI. > Yes thats right. I felt maybe Hook was overkill but then never mind. > >What I thought might be really useful is if one could use the select > >function call to wade through waiting sockets, thread queues or window > >events. > > In an ideal world, this isn't the optimal solution - if at all possible > you > want a single thread to block on the socket/thread queue/windows message > (a > blocked thread takes up no CPU cycles). When calling Win32::GUI::Dialog(); > in Win32-GUI what is actually happening is that the thread blocks waiting > for the next message. Say for example you wanted to build a win32-gui > application, which also had a web interface (for remote access), you would > have one thread blocking on the socket waiting for the http request, and > another thread blocking on the windows message queue via > Win32::GUI::Dialog() - that way you don't need to poll either the windows > messages or the socket. It's an optimal solution, because no CPU cycles > are > used waiting for a message and when a message does arrive the thread > responds immediately. On a dual core box, both threads would also run at > the > same time. > > Hope that makes some sense:) 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 :) Cheers, Emmanuel -- DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
