Rob/Jeremy, I went through the ThreadUtils code and this is what I understood: 1) Youre using a Hook to trap events/messages sent to window controls 2) These are enqueued 3) The trapped events/messages are passed onto the thread waiting on that queue All the above is packaged and the user sees two methods: Call and AttachComms.
Yeah, that's basically it. In the case of 3) above, what actually happens is that an event is triggered via the windows message queue.
But what I was thinking is that if the parent thread is doing Dialog() anyway and if the worker thread IS getting passed the window or the control in some form or the other it really dosent change things much.
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.
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.
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:) Cheers, jez.
