Ich erspare mir mal Kommentare zu sync/async und wer hier "zu langsam" ist.
Ganz BlackBox und allgemein:
- die
DLL ist hier der Master und erzeugt freundlicherweise NotifyEvents... dies tut sie aktuell via Aufruf einer CallBackFunktion
- wenn mein Programm das wäre, wessen CallBack da aufgerufen wird, dann MUSS ICH garantieren, das meine CallbackFunktion so schnell nur irgend geht funktioniert. Das kann ich per eigener Queue selbst machen oder ich nutze die WindowsMessageQueue... ist aber mein Bier und ich kann nicht erwarten, das die
DLL selbst auch noch so freundlich ist, mir alle Events zu synchronisieren und zu puffern. Wenn ich die
DLL "quäle" in dem meine Callbacks "zu lange" brauchen, kann es rein als Blackbox zwei Arten von Grundsatzproblemen geben:
- a: die
DLL und alles was sie macht hängt so lange ich meine ersten EventCallbackFunktion nicht beende und so die Ausführung zur
DLL zurückkehrt
- b: die
DLL ruft wie auch immer die EventCallbackFunktion nochmal/mehrmals auf, also voll rekursiv... darauf sollte dann aber sowohl die
DLL wie auch mein Programm vorbereitet sein
Wenn es nicht zuviel Aufwand ist, biete doch offiziell statt eines EventCallbacks auch eine Möglichkeit für eine EventMessage an, also lass deiner
DLL vom Hauptprogramm ein FansterHandle und eine MessageID geben, was du per PostMessage per WPARAM und LPARAM mit 2 Werten für EventType und EventValue fütterst.
Das spart viel Stress. Wenn mehr Daten zu übertragen sind dann die einfach per UDP über "
localhost" aus der
DLL heraus schicken... dann so eine C++ oder was auch immer Programm doch da die Daten "auffangen"... "Synchrone EventCallBacks" nutzen wir nur mit/zwischen "eigenen" Programmen und DLLs, externes
IPC wenn möglich per PostMessage oder per Pipe oder UDP.
Auf so Diskussionen über Schuld/Unschuld bei externen CallBacks verzichte ich, und realisiere es "asynchron" über einen vertrauenswürdigen
OS-Puffer, also MessageQueue,Pipes oder Socket
