Single-threaded asynchronous svrplus #198
Conversation
Right now this works similarly to the DialogBox function. Dialog end is done differently. EndDialog sets a flag in a struct and sends a WM_NULL to the window. The message loop checks the flag on each iteration, and if it's present, it terminates the loop, saves the return value (also from the same struct), and calls DestroyWindow. Aforementioned struct (called DIALOGINFO in Wine/ROS) is undocumented, so we have to do this ourselves. For simplicity, EndDialog is replaced with DestroyWindow+PostQuitMessage. This is less robust, but good enough for our purposes.
We only really need to wait for one object at the time, but: - it's only ~7 lines of code to make it work with 63 objects - we might want to install both things in parallel at some point
Now all blocking code is in ThreadProc
now it runs asnychronously
|
I'll need to take a closer look at this before merging, since I haven't used async functions on Windows. |
|
There seems to be some visual artifacting when updating the onscreen messages when registering/unregistering DLLs. I'll take a look at fixing this first. |
|
I'm not sure what's causing the weird window updating. Leaving this in feature/svrplus-async for now. EDIT: The DLLs aren't being registered in parallel; the WM_APP_TASK and WM_APP_SIGNAL messages are being used to handle this. However, using the message loop to handle processes is likely what's causing the visual artifacting. |
|
Check if visual artifacting is present in b557ed4 and the commit before it (or just bisect. each individual commit should compile, run and work). That commit is supposed to reimplement the DialogBoxW function so that GetMessage can be later replaced, and it might be missing something. |
Apparently all message-waiting functions are edge-triggered, not level-triggered as I thought. This should fix the graphical bugs. Obligatory oldnewthing link: <https://web.archive.org/web/20190127104202/https://blogs.msdn.microsoft.com/oldnewthing/20050217-00/?p=36423>
|
Looks like I forgot to notify you when I fixed this. I merged the changes from master and tested it, it seems to work fine. |
GerbilSoft
force-pushed
the
master
branch
2 times, most recently
from
dd3504b
to
0126a28
Compare
Well, turns out there is a way to do this without having to resort to multithreading. MsgWaitForMultipleObjects treats message queue as yet another object, allowing us to wait for regsvr32 to finish, while handling incoming messages on the same thread.
Why even bother? Well, IMO, multithreading should only be used when it's actually needed (i.e. in computationally expensive and/or unbounded code). Using it here was more of a hack than anything else. However, there is a benefit to this. Now it's very easy to make regsvr32 run for 32 and 64 bit DLLs at the same time. I'm not sure if that would be a sane thing to do, so I haven't looked into it yet, and I'm not including it in this PR.