Hi Olli
Heute morgen ist es mir wie Schuppen von den Augen gefallen: Der Parameter IdContext ist vom Typ AThread, und der wird bei den Sockets das erste mal deklariert und dann an alle Nachkommen weitergereicht,
damit diese eine CriticalSection für den existierenden Thread einrichten können.
Pro Anfrage existiert also genau ein Thread, und zwar genau so lange, bis dieser die Antwort über die Sockets ausgegeben hat. Natürlich kann es trotzdem zu Überschneidungen kommen; nämlich dann, wenn kurz nacheinander mehrere Threads gestartet werden, aber einer (oder mehrere) schneller arbeitet als andere.
Wenn dann die Anfrage beim Webmodul angekommen ist, ist ein Speicherzugriff ohne Criticalsection nicht mehr möglich, bzw. ein Hazzardspiel. Und das bedeutet, dass mein Konzept, dem Thread alle Infos beim Start mitzugeben, hier nicht möglich ist.
Zitat:
Aber dass bei Verwendung von TIdHttpServer, TIdHttpWebBrokerBridge etc. bereits "automatisch" mehrere Threads existieren, ist dir bewusst?
Sorry, das suggeriert eigentlich, das alle diese Klassen einen Thread einführen. Dabei übernehmen sie nur den einen (pro Aufruf) von ihrem Vorfahren im Parameter IdContext.
Gruss
Delbor