mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-06-04 10:50:29 -05:00
98538caa39
This is preparation to allow Pageant to be able to return to its GUI main loop in the middle of handling a request (e.g. present a dialog box to the user related to that particular request, and wait for the user's response). In order to do that, we need the main thread's Windows message loop to never be blocked by a WM_COPYDATA agent request. So I've split Pageant's previous hidden window into two hidden windows, each with a subset of the original roles, and created in different threads so that they get independent message loops. The one in the main thread receives messages relating to Pageant's system tray icon; the one in the subthread has the identity known to (old) Pageant clients, and receives WM_COPYDATA messages only. Each WM_COPYDATA is handled by passing the request back to the main thread via an event object integrated into the Pageant main loop, and then waiting for a second event object that the main thread will signal when the answer comes back, and not returning from the WndProc handler until the response arrives. Hence, if an agent request received via WM_COPYDATA requires GUI activity, then the main thread's GUI message loop will be able to do that in parallel with all Pageant's other activity, including other GUI activity (like the key list dialog box) and including responding to other requests via named pipe. I can't stop WM_COPYDATA requests from blocking _each other_, but this allows them not to block anything else. And named-pipe requests block nothing at all, so as clients switch over to the new IPC, even that blockage will become less and less common.