performance c++ <> Delphi

[mensch72]

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