Emmanuel E wrote:
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
Yes. The event has an application defined number, and carries an id as one of its parameters (wparam) that can be used by the receiving thread to look up the user-registered callback function.
2) These are enqueued
No. The parameters to Call() are put on the queue in the worker thread. The worker thread then sends a message to the gui thread, which causes Win32::GUI::Dialog in the gui thread to process the message. On processing the message the gui thread looks up the user-registered callback function, and pulls the parameters off the queue; it then dispatches the parameters to the callback function.
2) 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.
Correct. AttachComms, although callable as a method on a window/control object is actually a Win32::GUI::ThreadUtils object constructor; Call() is a Win32::GUI::ThreadUtils method.
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.
Right, but it generalises the interface and saves you having to write the code each time. It also deals with ensuring things are thread-safe by carefully locking the shared parameters whenever necessary.
The biggest advancement would be CLONE_SKIP, which allows you to create threads later.
Indeed - I was somewhat surprised how easy making Win32::GUI was once I had discovered this feature.
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.
It's not that easy, and you really want to have your UI running in a separate thread from other asynchronous activity, as Windows has plenty of other ways of locking the UI thread. For example whenever a menu is displayed, or you are dragging or resizing a window the UI thread will be non-responsive as these feature use their own message loops.
Regards, Rob.
