Konzept: Netzwerkprotokoll

[Zacherl]

Zitat von Sir Rufo:

Ich habe auch nicht gesagt, dass das nicht funktioniert, es gibt aber ein ganz schmales Zeitfenster, wo das nicht funktioniert.
Das doofe daran ist, wenn man es gar nicht gebrauchen kann, dann schlägt das zu (Murphy)

Irgendwie stehe ich hier auf dem Schlauch Ich prüfe doch direkt nach dem WaitForSingleObject auf Terminated. Und in der überschriebenen Terminate Funktion des Threads setze ich erst Terminated und dann löse ich das Event aus. Aber wie auch immer ..

Zitat von Sir Rufo:

Hier mal mein Vorschlag für den Händler

.. dein Ansatz mit der Queue sieht sehr gut aus Muss ich mir mal genauer anschauen, ob die TQueue Klasse von Delphi das Verschieben von Einträgen unterstüzt oder mir was eigenes basteln. Wollte dem User die Möglichkeit lassen, die Reihenfolge der Übertragungen zu ändern.

[Sir Rufo]

Zitat von Zacherl:

Zitat von Sir Rufo:

Ich habe auch nicht gesagt, dass das nicht funktioniert, es gibt aber ein ganz schmales Zeitfenster, wo das nicht funktioniert.
Das doofe daran ist, wenn man es gar nicht gebrauchen kann, dann schlägt das zu (Murphy)

Irgendwie stehe ich hier auf dem Schlauch Ich prüfe doch direkt nach dem WaitForSingleObject auf Terminated. Und in der überschriebenen Terminate Funktion des Threads setze ich erst Terminated und dann löse ich das Event aus. Aber wie auch immer ..

Folgendes Szenario:
Der Thread holt sich über die LockList die Transfer-Elemente und kopiert diese. Dann gibt er diese LockList wieder frei. Genau zu diesem Zeitpunkt wird der Thread terminiert (FWaitEvent wird gesetzt und der Thread auf Terminated). Jetzt sind aber keine Elemente in der Liste, also setzt der Thread das FWaitEvent zurück und wartet darauf, dass das Event kommt (unendlich).
Der Thread wird also nicht beendet

Dies ist zwar theoretisch aber ich habe bei genau sowas schon die kotzenden Pferde gesehen.
Bis du dann dem Entwickler dediziert beschreiben und vor allem nachweisen kannst, dass da was falsch läuft - gute Nacht Marie

Zitat von Zacherl:

Zitat von Sir Rufo:

Hier mal mein Vorschlag für den Händler

.. dein Ansatz mit der Queue sieht sehr gut aus Muss ich mir mal genauer anschauen, ob die TQueue Klasse von Delphi das Verschieben von Einträgen unterstüzt oder mir was eigenes basteln. Wollte dem User die Möglichkeit lassen, die Reihenfolge der Übertragungen zu ändern.

Dafür benötigst du eine sortierte Liste (mit einem Comparer)
TComparer<T>

Die Send-Queue würde ich aber genau so nehmen und die Reihenfolge nur für die wartenden Transfers berücksichtigen.

[Zacherl]

Zitat von Sir Rufo:

Dies ist zwar theoretisch aber ich habe bei genau sowas schon die kotzenden Pferde gesehen.
Bis du dann dem Entwickler dediziert beschreiben und vor allem nachweisen kannst, dass da was falsch läuft - gute Nacht Marie

Ahh danke für die Erläuterung, jetzt sehe ich das Problem auch. Habe eben schon ein DeadLock gefixt, da kann ich dir nur zustimmen: Bist man sowas zuverlässig reproduziert und gefunden hat, kann schonmal einige Zeit vergehen.

Den Comparer werde ich mir mal anschauen. Muss zugeben, dass ich mit den Generic Klassen von Delphi bisher kaum gearbeitet habe. Das Comperator Konzept ist mir allerdings von Java her bekannt. Prinzipiell könnte ich für die "WaitQueue" ja aber auch meine alte Lister weiter verwenden.

Eine Frage noch zu deinem Ansatz:
Du deklarierst die SendDataPacket Funktion als protected im IOHandler. Die Funktion muss allerdings vom Thread heraus aufgerufen werden. Ich weiß zwar, dass ein Zugriff (sogar auf private) Felder innerhalb der selben Unit klassenübergreifend möglich ist, aber meiner Meinung nach ist das eher schlechter Stil oder nicht?

[Sir Rufo]

Zitat von Zacherl:

Du deklarierst die SendDataPacket Funktion als protected im IOHandler. Die Funktion muss allerdings vom Thread heraus aufgerufen werden. Ich weiß zwar, dass ein Zugriff (sogar auf private) Felder innerhalb der selben Unit klassenübergreifend möglich ist, aber meiner Meinung nach ist das eher schlechter Stil oder nicht?

Nein, das ist kein schlechter Stil.

Die Methode SendDataPacket soll vom Thread aufgerufen werden können, aber nicht vom Rest der Welt.
Bei einigen Programmiersprachen habe ich diese Möglichkeit nicht und muss diese Methode tatsächlich als public deklarieren, obwohl ich das gar nicht möchte.

Delphi bietet mir die Möglichkeit (protected vs. strict protected) warum sollte man das dann nicht nutzen?

[Zacherl]

Zitat von Sir Rufo:

Die Methode SendDataPacket soll vom Thread aufgerufen werden können, aber nicht vom Rest der Welt.
Bei einigen Programmiersprachen habe ich diese Möglichkeit nicht und muss diese Methode tatsächlich als public deklarieren, obwohl ich das gar nicht möchte.

Delphi bietet mir die Möglichkeit (protected vs. strict protected) warum sollte man das dann nicht nutzen?

Weiß auch nicht, warum ich bisher immer davon ausgegangen bin, dass das schlechter Stil ist Das hilft mir auf jeden Fall sogar noch bei 1-2 weiteren OO Design Problemen im Netzwerkprotokoll weiter. Dann werde ich wohl auch hingehen und sämtliche Sende- und Empfangsmethoden vom Thread in den IOHandler verschieben, wo sie ja auch im Grunde genommen hingehören.

[Sir Rufo]

Zitat von Zacherl:

Zitat von Sir Rufo:

Die Methode SendDataPacket soll vom Thread aufgerufen werden können, aber nicht vom Rest der Welt.
Bei einigen Programmiersprachen habe ich diese Möglichkeit nicht und muss diese Methode tatsächlich als public deklarieren, obwohl ich das gar nicht möchte.

Delphi bietet mir die Möglichkeit (protected vs. strict protected) warum sollte man das dann nicht nutzen?

Weiß auch nicht, warum ich bisher immer davon ausgegangen bin, dass das schlechter Stil ist Das hilft mir auf jeden Fall sogar noch bei 1-2 weiteren OO Design Problemen im Netzwerkprotokoll weiter. Dann werde ich wohl auch hingehen und sämtliche Sende- und Empfangsmethoden vom Thread in den IOHandler verschieben, wo sie ja auch im Grunde genommen hingehören.

Weil es unorthodox aussieht und hier ja auch schon Diskussionen geführt worden sind, dass Delphi da inkonsequent wäre (im Vergleich zu anderen Sprachen).

[BUG]

Zitat von Sir Rufo:

Weil es unorthodox aussieht und hier ja auch schon Diskussionen geführt worden sind, dass Delphi da inkonsequent wäre (im Vergleich zu anderen Sprachen).

Java hat ja die default-Sichtbarkeit (sichtbar im Package) und in anderen Sprachen (C++) gibt es dafür Freund-Klassen/Methoden ... so ungewöhnlich ist es eigentlich nicht