Stataskscheduler i STA thread message

Moje zrozumienie twojego problemu: używasz StaTaskScheduler tylko do zorganizowania klasycznego mieszkania COM STA dla twoich starych obiektów COM. Nie uruchamiasz pętli wiadomości WinForms lub WPF w wątku STA StaTaskScheduler. Oznacza to, że nie używasz niczego takiego jak Application.Run, Application.DoEvents albo Dispatcher.PushFrame wewnątrz tego wątku. Popraw mnie, jeśli to błędne założenie.

By itself, StaTaskScheduler nie instaluje żadnego kontekstu synchronizacji na utworzonych przez siebie wątkach STA. Tak więc, jesteś opierając się na CLR pompować wiadomości dla Ciebie. W 2011 roku, w ramach projektu "the CLR pumps", w ramach projektu "the CLR pumps", w ramach projektu " the CLR pumps in the STA threads, in Apartments and Pumping in the CLR by Chris Brumme:

Powtarzam, że zarządzane blokowanie wykona "pewne pompowanie", gdy / align = "left" / Czy nie byłoby wspaniale wiedzieć dokładnie, co będą pompowane? Niestety pompowanie to czarna sztuka, która jest poza śmiertelnym zrozumieniem. Na Win2000 i up, po prostu delegujemy do Serwis OLE32

Oznacza to, że CLR używa CoWaitForMultipleHandles wewnętrznie dla wątków STA. Ponadto dokumenty MSDN dla znacznika COWAIT_DISPATCH_WINDOW_MESSAGES wspominają o tym :

... w STA jest tylko mały zestaw wiadomości wysyłanych w specjalnej obudowie.

Zrobiłem kilka badań na ten , ale nie mogłem dostać się do pompowania WM_TEST z twojego przykładowego kodu z CoWaitForMultipleHandles, omówiliśmy to w komentarzach do twojego pytania. My zrozumienie jest, wspomniany mały zestaw wiadomości specjalnych jest naprawdę ograniczona do niektórych komunikatów specjalnych i nie zawiera żadnych regularnych wiadomości ogólnego przeznaczenia, takich jak twoje WM_TEST.

Więc, aby odpowiedzieć na twoje pytanie:

... Czy powinienem zaimplementować Niestandardowy kontekst synchronizacji, który bezpośrednio pompuj wiadomości za pomocą CoWaitForMultipleHandles i zainstaluj je na każdym wątku STA rozpoczętym przez StaTaskScheduler?

Tak, uważam, że stworzenie własnego kontekstu synchronizacji i nadpisanie SynchronizationContext.Wait jest rzeczywiście właściwym rozwiązaniem.

Należy jednak unikać używania CoWaitForMultipleHandlesi MsgWaitForMultipleObjectsEx zamiast . Jeśli MsgWaitForMultipleObjectsEx wskazuje, że w kolejce jest oczekująca wiadomość, należy ręcznie pompować ją za pomocą PeekMessage(PM_REMOVE) i DispatchMessage. Następnie należy nadal czekać na uchwyty, wszystkie wewnątrz tego samego wywołania SynchronizationContext.Wait.

Uwaga jest subtelny, ale ważna różnica pomiędzy MsgWaitForMultipleObjectsEx A MsgWaitForMultipleObjects. Ten ostatni nie powraca i blokuje, jeśli w kolejce jest już widoczna wiadomość (np. z PeekMessage(PM_NOREMOVE) lub GetQueueStatus), ale nie jest usuwany. To nie jest dobre do pompowania, ponieważ obiekty COM mogą używać czegoś w rodzaju PeekMessage do sprawdzania kolejki komunikatów. Może to później spowodować blokadę MsgWaitForMultipleObjects, gdy nie jest to oczekiwane.

OTOH, MsgWaitForMultipleObjectsEx z MWMO_INPUTAVAILABLE flaga nie ma takich niedociągnięć i wróciłaby w tym case.

Jakiś czas temu stworzyłem własną wersję StaTaskScheduler (dostępne tutaj jako ThreadAffinityTaskScheduler) w celu rozwiązania innego problemu: utrzymanie puli wątków z powinowactwem wątków do kolejnych await kontynuacji. Powinowactwo wątku jest istotne jeśli używasz obiektów STA COM w wielu awaits. The original StaTaskScheduler wykazuje to zachowanie tylko wtedy, gdy jego pula jest ograniczona do 1 wątku.

Więc poszedłem do przodu i zrobiłem trochę więcej eksperymentowanie ze sprawą WM_TEST. Pierwotnie zainstalowałem instancję standardu SynchronizationContext zajęcia na wątku STA. WM_TEST wiadomość nie została napompowana, co było oczekiwane.

Then I overridden SynchronizationContext.Wait aby przesłać go doSynchronizationContext.WaitHelper. Dzwonili, ale i tak nie pompowali.

// the core loop
var msg = new NativeMethods.MSG();
while (true)
{
    // MsgWaitForMultipleObjectsEx with MWMO_INPUTAVAILABLE returns,
    // even if there's a message already seen but not removed in the message queue
    nativeResult = NativeMethods.MsgWaitForMultipleObjectsEx(
        count, waitHandles,
        (uint)remainingTimeout,
        QS_MASK,
        NativeMethods.MWMO_INPUTAVAILABLE);

    if (IsNativeWaitSuccessful(count, nativeResult, out managedResult) || WaitHandle.WaitTimeout == managedResult)
        return managedResult;

    // there is a message, pump and dispatch it
    if (NativeMethods.PeekMessage(out msg, IntPtr.Zero, 0, 0, NativeMethods.PM_REMOVE))
    {
        NativeMethods.TranslateMessage(ref msg);
        NativeMethods.DispatchMessage(ref msg);
    }
    if (hasTimedOut())
        return WaitHandle.WaitTimeout;
}

To działa, WM_TEST jest pompowane. Poniżej znajduje się dostosowana wersja testu:

public static async Task RunAsync()
{
    using (var staThread = new Noseratio.ThreadAffinity.ThreadWithAffinityContext(staThread: true, pumpMessages: true))
    {
        Console.WriteLine("Initial thread #" + Thread.CurrentThread.ManagedThreadId);
        await staThread.Run(async () =>
        {
            Console.WriteLine("On STA thread #" + Thread.CurrentThread.ManagedThreadId);
            // create a simple Win32 window
            IntPtr hwnd = CreateTestWindow();

            // Post some WM_TEST messages
            Console.WriteLine("Post some WM_TEST messages...");
            NativeMethods.PostMessage(hwnd, NativeMethods.WM_TEST, new IntPtr(1), IntPtr.Zero);
            NativeMethods.PostMessage(hwnd, NativeMethods.WM_TEST, new IntPtr(2), IntPtr.Zero);
            NativeMethods.PostMessage(hwnd, NativeMethods.WM_TEST, new IntPtr(3), IntPtr.Zero);
            Console.WriteLine("Press Enter to continue...");
            await ReadLineAsync();

            Console.WriteLine("After await, thread #" + Thread.CurrentThread.ManagedThreadId);
            Console.WriteLine("Pending messages in the queue: " + (NativeMethods.GetQueueStatus(0x1FF) >> 16 != 0));

            Console.WriteLine("Exiting STA thread #" + Thread.CurrentThread.ManagedThreadId);
        }, CancellationToken.None);
    }
    Console.WriteLine("Current thread #" + Thread.CurrentThread.ManagedThreadId);
}

Wyjście :

Initial thread #9
On STA thread #10
Post some WM_TEST messages...
Press Enter to continue...
WM_TEST processed: 1
WM_TEST processed: 2
WM_TEST processed: 3

After await, thread #10
Pending messages in the queue: False
Exiting STA thread #10
Current thread #12
Press any key to exit

Uwaga Ta implementacja obsługuje zarówno powinowactwo wątku (pozostaje w wątku #10 po await), jak i pompowanie wiadomości. Pełny kod źródłowy zawiera części wielokrotnego użytku (ThreadAffinityTaskScheduler i ThreadWithAffinityContext) i jest dostępny tutaj jako samodzielna aplikacja konsoli . Nie został dokładnie przetestowany, więc używaj go na własne ryzyko.