![]() |
AW: Problem mit TImage
Zitat:
Eine Server Komponente (idR für eine Verbindung zu 1+ Clients) läuft entweder sehr schlecht oder pro Client-Verbindung in einem Thread. Ob die Komponente jetzt von INDY oder wem auch immer ist, ist dabei egal :stupid: |
AW: Problem mit TImage
Ich will den Thread nicht "hijacken" man möge mich also bremsen/zurechtweisen/strafen.
In diesem Beispiel geht es um UDP. Je nach Komponente ist die Implementierung eines UDP-Servers Multithreading in Eigenverantwortung (zB Indy) oder in Komponentenverantwortung (zB ICS). Nach meinem Verständnis der VCL ist letzteres eher der "Delphi-way". Das "blutige" ist weggekapselt, der Entwickler muss sich keine Gedanken darum machen. Darum mein "ach, es ist ja Indy". Sherlock |
AW: Problem mit TImage
Ich wollte nur vorbeugen, falls jetzt der Eindruck (bei wem auch immer) entsteht, man müsste nur etwas anderes als Indy nehmen und dann bräuchte man kein Synchronisieren :stupid:
|
AW: Problem mit TImage
Tja,
bei mir leider nix neues. Wie gesagt, Komponente steht auf Treaded:=true Verwende ich die "Syncroniz-Kapselung" wie in Sir Rufo´s Beispiel auf Seite 1 wird UDP Read nicht mehr angesprungen. |
AW: Problem mit TImage
Habs nur ein bisschen umgebaut:
Delphi-Quellcode:
Nun wird hier nur der Empfangsbuffer in einen lokalen kopiert und dann in "Do Something"
procedure TForm1.ServerUDPRead(AThread: TIdUDPListenerThread;
const AData: TIdBytes; ABinding: TIdSocketHandle); begin TThread.Synchronize( nil, procedure begin setlength(Buffer,length(AData) ); move(AData,Buffer,length(AData) ); Do_Something; end ); end; ausgewertet. Sende ich was per UDP hält das Programm in der Zeile TThread.Sync... einmal an und dann nie wieder :-( |
AW: Problem mit TImage
Warum willst du die Auswertung synchronisiert vornehmen?
Die Ausgabe an die Controls muss synchronisiert erfolgen, die Auswertung, etc. eher nicht (das ist da wurscht) bzw. eher hinderlich, weil jetzt jeder Empfangsthread den MainThread sehr lange blockiert und dann stehen sich alle auf den Füßen rum. Stell dir vor du bist der Chef und deine Mitarbeiter bearbeiten emails. Es darf immer nur einer mit dir sprechen. Jetzt öffnet jeder Mitarbeiter eine email und sucht das Gespräch mit dir (wartet höflich bis er an der Reihe ist), um dir die ganze email vorzulesen ... und dir ganz zum Schluss mitteilt, ob die nun für dich relevant ist oder nicht. Wäre es nicht günstiger von der Zeit und für deine Ohren, wenn jeder Mitarbeiter die email erst einmal still und heimlich vor sich hin liest und dir nur eine kurze Rückmeldung gibt (wenn es wichtig ist)? Du versuchst gerade die ungünstige Variante |
AW: Problem mit TImage
Hi Rufo,
Denke das Problem ist das ich die Vorgehensweise / dem Sinn der Syncronisierung nicht verstanden hab. Bin nicht so der Crack der das schon jahrelang macht. Bei Themen wie Cortex M0/M7 könnte ich eher helfen. Da unter einem RTOS Threadprioritäten zu verteilen oder mit dem NVIC zu arbeiten finde ich wesentlich logischer. Bisher war mein Gedanke das wenn ich "Threaded" aktiviere der Empfang mehr oder weniger unabhängig vom Rest läuft und ich trotz UDP nix verpasse. Nun kopiere ich mir den Empfangspuffer in einen lokalen und murkse dann weiter. Gruss Calli |
AW: Problem mit TImage
Das passiert ja auch alles threaded, aber wenn du dieses schöne Nebeneinander wieder durch eine Synchronisierung in ein Hintereinander presst, dann hat es sich eben mit dem Nebeneinander erledigt.
Hier ein kleines Minimal-Beispiel:
Delphi-Quellcode:
procedure WillBeCalledFromAThread( foo: TFoo );
var i:Integer; begin // ** Im Thread // Ganz was Aufwändiges berechnen Sleep( 5000 ); // unser Ergebnis i := 1; // Das Ergebnis in der Form anzeigen, das dürfen wir aber nur synchronisiert TThread.Synchronize( nil, procedure begin // ** Im MainThread // Berechnung hier? // Sleep( 5000 ); // <- würde das Programm für den Benutzer für 5 Sekunden blockieren // also doof, lieber vorher berechnen, da stört es nicht MyForm.ListBox.Items.Add( IntToStr( i ) ); end); // ** Im Thread // nochwas machen? end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:59 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz