Functionality to wait for Win32 event object in the dispatcher?

[Berrysoft]

The question might be wierd, but I would like the functionality to wait for a Win32 event handle in the UI thread without blocking UI, just like MsgWaitForMultipleObjectsEx. Is there such thing in WinUI2/WinUI3?

[castorix]

A way can be with ThreadPool.RegisterWaitForSingleObject

Something like :

  [DllImport("Kernel32.dll", SetLastError = true)]
  public static extern IntPtr CreateEvent(IntPtr lpEventAttributes, bool bManualReset, bool bInitialState, string lpName);

  [DllImport("Kernel32.dll", SetLastError = true)]
  public static extern bool SetEvent(IntPtr hEvent);

private IntPtr m_pEventHandle;
private EventWaiter m_Waiter;  

  m_pEventHandle = CreateEvent(IntPtr.Zero, true, false, null); 
  m_Waiter = new EventWaiter(this);
  m_Waiter.WaitEventNonBlocking(m_pEventHandle);

  // Simulate signaling the event after 5 seconds
 _ = new Timer(_ =>
 {
     SetEvent(m_pEventHandle);
 }, null, 5000, Timeout.Infinite);

public class EventWaiter
 {
     private Microsoft.UI.Dispatching.DispatcherQueue m_DispatcherQueue;
     private readonly Window m_MainWindow;

     public EventWaiter(Window window)
     {
         m_MainWindow = window;
         m_DispatcherQueue = m_MainWindow.DispatcherQueue;
     }

     public void WaitEventNonBlocking(IntPtr pHandle)
     {
         var autoResetEvent = new AutoResetEvent(false)
         {
             SafeWaitHandle = new Microsoft.Win32.SafeHandles.SafeWaitHandle(pHandle, ownsHandle: false)
         };

         ThreadPool.RegisterWaitForSingleObject(
             autoResetEvent,
             (state, timedOut) =>
             {
                 m_DispatcherQueue.TryEnqueue(() =>
                 {
                     System.Diagnostics.Debug.WriteLine("Win32 event was signaled!");
                 });
             },
             null,
             Timeout.Infinite,
             true
         );
     }
 }

[DarranRowe]

This should be pretty easy for C++ using coroutines.

    void MainWindow::myButton_Click(IInspectable const&, RoutedEventArgs const&)
    {
        DispatcherQueue().TryEnqueue([this, evt = m_evt]() -> winrt::Windows::Foundation::IAsyncAction
            {
                auto shared_this = shared_from_this();
                co_await winrt::resume_background();
                auto wfso_result = WaitForSingleObject(evt, INFINITE);
                co_await wil::resume_foreground(DispatcherQueue());
                //Do what needs to happen here. This is executing on the UI thread.
                co_return;
            }
        );
    }

The two big points to note is that the MainWindow class also derives from std::enable_shared_from_this. This is to stop the window being destroyed while the coroutine is still active. Second, I use evt=m_evt for one of the lambda captures. This is really showing a bit more clearly that the event is a data member of MainWindow. Because this was captured too, it is possible to ommit this and just use m_evt.

[Berrysoft]

Seems that TryEnqueue only accepts sync functions? Is it valid to pass a coroutine?

[DarranRowe]

If a coroutine is written correctly, which the C++/WinRT ones are, then they will work pretty similarly to syncronous functions.

But it is also supported based upon the fact that winrt::resume_background and wil::resume_foreground exist. The entire purpose of winrt::resume_background is to move a coroutine running as a task on a Dispatcher/DispatcherQueue to a thread pool thread. The entire purpose of wil::resume_foreground is to move a coroutine running on a background thread to a task running on the UI thread by enqueueing it on the Dispatcher/DispatcherQueue. If you look at the code for WIL, you will find that it will use TryEnqueue itself.

[DarranRowe]

Also, to give a bit more context, there is a bit of a switcharoo going on under the surface, since even though a lambda is passed into TryEnqueue, TryEnqueue only accepts DispatcherQueueHandler objects as the parameter. The lamdba passed in is used internally, but an object of type DispatcherQueueHandler is constructed as part of the call, and DispatcherQueueHandler is a functor with an operator()*. The dispatcher queue calls the DispatcherQueueHandler's operator() and this in turn calls the coroutine lambda.

So a synchronous function is provided as part of the DispatcherQueueHandler.

As a bit of an illustration as to what is going on under the surface in Windows API terms, please look at this repository. I completely stripped away all WinUI and WinRT related functionality with only standard C++ and Windows API functionality doing what happens with the thread pool and dispatcher queue.

*This isn't exactly accurate due to the COM based nature, but it is close enough in C++ terms to explain things.

[lgztx96]

You can refer to https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/concurrency-3#source-code-for-the-completion_source-sample