Carbon ReceiveNextEvent und sekundäre Threads

Question

Stellen Sie sich eine plattformübergreifende Bibliothek vor, die ihr eigenes Windows erstellen muss, ohne sich auf WinForms/GTK#/WPF/MonoMac/etc zu verlassen (dies ist OpenTK für den Fall, dass jemand daran interessiert ist).

Hier ist der Deal: Windows und X11-fähige Unices unterstützen (oder können mit ihnen arbeiten) mehrere Ereignisschleifen, eine auf jedem Thread. Das bedeutet, (a) Sie können ein Fenster pro Thread erstellen und sie unabhängig voneinander arbeiten lassen und (b) Sie können ein WinForms-Fenster (oder GTK#, WPF, ...) auf einem Thread ausführen und ein OpenTK-Fenster auf einem anderen öffnen, ohne dass es zu Störungen kommt.

Meinem - zugegebenermaßen begrenzten - Wissen nach unterstützt Carbon dies jedoch nicht. OS-Ereignisse werden nur an die "Haupt"-Ereignisschleife geliefert und alle sekundären Threads laufen auf Sparflamme (d.h. ReceiveNextEvent gibt immer eventLoopTimedOutErr zurück und findet keine Ereignisse). OpenTK selbst kann mit dieser Einschränkung problemlos arbeiten, aber dies stellt ein interessantes Problem für Anwendungen dar, die versuchen, OpenTK mit einem anderen Toolkit (z.B. MonoMac) zu mischen, um ein Konfigurationsfenster zu präsentieren.

Zwei Möglichkeiten:

• die Idee als verrückt zu verwerfen und das Mischen von OpenTK mit verschiedenen Toolkits zu verbieten (schlecht).
• Nehmen Sie eine Streitaxt und hacken Sie Carbon in die Knie (gut).

Hier kommen Sie ins Spiel: Fällt Ihnen eine Möglichkeit ein, wie das funktionieren könnte? Stellen Sie sich das folgende Szenario vor:

1. Thread Nr. 1 (main) führt einen Initialisierungscode unserer Wahl aus und legt einen zweiten Thread an (wir können diesen frei ändern).
2. Thread 1 (main) öffnet ein natives Fenster und führt eine RAEL-Schleife (RunApplicationEventLoop) aus. Er entzieht sich unserer direkten Kontrolle, obwohl wir bei Bedarf immer noch Zeitgeber installieren können, um unseren Code auszuführen.
3. Thread #2 (sekundär) öffnet ein OpenTK-Fenster, das sich prompt aufhängt (Ereignisse werden nur an Thread #1 geliefert und ReceiveNextEvent erhält nichts).

Ist es möglich, Ereignisse aus Thread 1 zu filtern und sie bei Bedarf an Thread 2 weiterzuleiten? Könnte CF hier irgendwie helfen? Gurus von Mac OS X, bitte helfen Sie!

(Die Programmiersprache spielt keine Rolle, verwenden Sie alles, womit Sie vertraut sind. Ich würde eine Carbon-basierte Lösung bevorzugen, aber Cocoa würde auch gut funktionieren).

Answer 1

Die Übergabe der Ereignisse von einem Thread zum anderen sollte so weit funktionieren, dass die Ereignisse einfach zugestellt werden. Der heikle Teil ist, dass viele der UI-bezogenen APIs nicht thread-sicher sind, auch wenn der Kern Carbon Event Handling ist. Alles, was mit der Aktualisierung von Steuerelementen und dem Zeichnen zu tun hat, sollte wahrscheinlich im Hauptthread behandelt werden. Das würde eine Menge hin und her erfordern, und es lohnt sich vielleicht nicht, zu versuchen, es zum Laufen zu bringen.

Answer 2

Werfen Sie einen Blick auf Anwendung.AddMessageFilter とのことです。 IMessageFilter Schnittstelle. Sie könnte in der Lage sein, Nachrichten mit Hilfe einer benutzerdefinierten Logik abzufangen und weiterzuleiten. Ich habe diese Technik in der Vergangenheit verwendet (sehr weit zurückliegend), aber es ist schon so lange her, dass ich mich nicht mehr an alle damit verbundenen Vorbehalte erinnern kann. Ich bin nicht einmal sicher, dass der Nachrichtenfilter alle Nachrichten empfängt. .NET filtert sie möglicherweise nicht hinter den Kulissen heraus, bevor es sie an die IMessageFilter aber einen Versuch ist es wert.