In `plugplay_send_event`, the `WM_DEVICECHANGE` broadcast was changed in f5ca06016db to be asynchronous, as the commit documents that doing so otherwise would cause `BroadcastSystemMessageW` to timeout while waiting for a response from the window threads. The new code does the same, but needs to first allocate an `DEV_BROADCAST_DEVICE_W` object first. However, since async broadcasts use `SendNotifyMessageW`, this should result in a dangling pointer, as the allocated `DEV_BROADCAST_DEVICE_W` gets freed after the two broadcast calls.
That being said, shouldn't this also be the case for the current code as well? `data`'s lifetime is limited to `plugplay_send_event`, and would be invalid as soon as `plugplay_send_event` returns. I imagine the new code is more crash-prone, as the `DEV_BROADCAST_DEVICE_W` object on the heap is going to get immediately freed, as opposed to the current code, where `data` sticks around for a bit longer, allowing receiving threads to get away with accessing the memory.
Would it be a better idea to separate this code into its own thread, where the broadcast is made synchronously? I'm thinking something like `plugplay_send_event` appending a copy of the event to a new queue, which then gets drained by another thread, with an event object to let the thread know that there are new events to synchronously broadcast. Thoughts?