In der damaligen Diskussion in den NewsGroups stellten sich zwei mögliche Lösungen:
1.) RecyclerMM exportiert eine Funktion zb. DoneMM() die der Programmierung am Ende eines Threads aufzurufen hat.
2.) RecyclerMM exportiert eine Funjtion zb. CleanupMM() die der Programmierer periodisch aufzurufen hat oder aber innerhalb vom RecyclerMM() periodsich per Timer aufgerufen wird.
Nun analysieren wir das mal:
1.) falls wir einen
COM/
ActiveX Service oder eine
DLL programmieren dann kann diese durch externe Prozesse aufgerufen werden die NICHT durch uns selber programiert wurden, sondern zb. in VB, C oder sonstwas. Ergo: DoneMM() kann und wird garnicht aufgerufen. Diese Lösung fehlt also ins Wasser.
2.) falls wir einen
COM/
ActiveX Service oder eine
DLL programmieren dann kann diese durch externe Prozesse aufgerufen werden die NICHT durch uns selber programmiert wurden, sondern zb. in VB, C oder sonstwas
Ergo: CleanupMM() wird nicht aufgerufen.
Selbst aber ein Timer basiertes Aufrufen von CleanupMM() muß scheitern da RecyclerMM innerhlab dieser Funktion garnicht unterscheiden kann ob ein Thread noch läuft, nur gestoppt wurde oder aber tatsächlich terminiert wurde. Man kann zwar per Trial&Error versuchen herauszubekommen ob ein Thread-
Handle oder Thread-ID ungültig ist aber dies würde nur funktionieren wenn das
OS dokumentiert sicherstellen würde das ein einmal benutzte Thread ID oder Thread
Handle nicht mehr wiederbenutzt wird. Nun, Windows garantiert eine solche Vorgehensweise aber nicht !!
Ergo: es entstehen viel zu viele Unwägbarkeiten, bis hin zu "fehlerhaften" Benutzung des MMs durch uns selber. Ein guter MM muß aber in solchen Sachen wirklich Bullet Proof konstruiert sein. D.h. das Konzept muß so konstruiert werden das es keine Möglichkeit für eine "Fehlbenutzung" durch andere Programmierer kommen kann.
Übrigens, ich rede hier nicht von theoretischen Dingen, sondern aus selber gemachten Erfahrungen. Eine
TCP/
IP Service der per
COM Schnittstelle aufgerufen werden konnte wurde mit RecyclerMM ausgestattet. Eben weil sehr viele, große und häugfige Speicheranforderungen stattfanden und ich mir vom RecyclerMM einen Performanceboost erhoffte. Dies war auch in den Tests wunderbar der Fall, mit einem Schönheitsfehler: Die Tests wurden auf Grund der äußeren Umstände immer nur so durchgeführt das nur eine
TCP/
IP Clientverbindung stattfinden konnte. Dieser Test simulierte also NUR die technische Funktionaliät aber NICHT die praxisnahe reale Auslastung mit 1000'enden Clients innerhlab von Sekunden. Als es dann soweit war, Abnahme war gemacht, Kunde hattte bezahlt und ging in den Echtbetrieb kackte der Server ständig schon teilweise nach Minuten komplett ab. So, die Suche konzentierte sich naturgemäß erstmal nur auf den Server, dessen
TCP/
IP Konfigurationen, auf die Router, neueste Patches etc. pp. Dies verschlang Wochen da es sehr schwer nachvollziehbar war und die Clientlast sich sehr unregelmäßig verteilte. Erst nachdem ich eine zusätzliche Anwendung programmierte die 1000'ende Clients simulierte konnten wir das Problem eingrenzen. Natürlich kam ich nicht sofort auf die Idee den fucking RecyclerMM zu deaktievieren sondern ging stur von einem Fehler in meinen Sourcen und später in
Indy's Sourcen aus. Naja, nach 6 Wochen schmiß ich RecyclerMM auf Grund eines systematischen Vorgehens, also Routine, verdchatsweise raus. Danach ging alles wie gehabt. Also nochmal 1 Woche programmiert um alle Sourcen wieder auf ihren Auslieferungszustand zu versetzenund schlußendlich habe ich länger daran gesessen diesen Fehler zu entfernen als das eigentlichen Projekt zu seiner Fertigstellung an Zeit erfodert hatte !! Die Entwicklungszeit verlängerte sich also von 5 Wochen auf +7 Wochen. Meine finanzielle Kalkulation war fürn Popo.
Gruß Hagen