On Fri Aug 30 18:00:21 2024 +0000, Vibhav Pant wrote:
> > Maybe we can avoid sending the paths every time by moving the
> filtering to plugplay, adapting the interface a bit for this. There
> could be additional methods to register paths / get plugplay handles in
> return, and later use these handle as device handles.
> Perhaps, but wouldn't this make both plugplay service, and the
> notification code sechost/service.c a lot more stateful as a result? Re:
> device handles, if you're referring to the `dbch_handle` field in
> `DEV_BROADCAST_HANDLE`, we already get that from the user using
> `RegisterDeviceNotification`, and the current code just uses them for
> sending notifications.
I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time.
> Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications.
Fwiw I'm fine keeping the paths, and using the `reserved` field to describe them. I was just considering additional improvements but this specifically doesn't need to be done now.
However, passing process-private handles around to other processes and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80567