Hallo,
meine Applikation kann sowohl als GUI Applikation als auch als Service gestartet werden und kommuniziert über einen oder mehrere Comports also auch mit dem Firebird Server über IBObjects. Als Applikation läuft alles wunderbar. Wird das ganze als Service gestartet läuft es zwar prinzipiell auch, jedoch crasht es meist nach wenigen Minuten. Als Ursache habe ich die offenbar parallele Abarbeitung von Ereignissen des Comports (OnRxChar, OnTimeOut, On SendData) erkannt, d.h. bei Betrieb als Applikation werden diese Ereignisse wie zu erwarten (werden von der TComport Komponente (von WinSoft.sk) da mit Synchronize aus dem Comport Thread aufgerufen streng sequentiell abgearbeitet. Bei Betrieb als Service werden diese Ereignisse teilweise gleichzeitig abgearbeitet - d.h. während gerade Daten empfangen werden wird das timer gesteuerte Ereignis SendData abgearbeitet - die Events scheinen sich gegenseitig zu unterbrechen (Interrupt like), was darauf hindeutet, das die Synchronizeaufrufe nicht mehr mit dem hauptthread synchronisiert werden ?
Warum unterscheidet sich die Ereignisbearbeitung bei Betrieb als Applikation und als Service ?

mfg

Klaus

Zitat von Niotronic:

was darauf hindeutet, das die Synchronizeaufrufe nicht mehr mit dem hauptthread synchronisiert werden ?

Synchronize synchronisiert mit dem VCL Hauptthread. Es ist gefährlich in einer nicht-VCL Anwendung synchronize zu verwenden. Ich würde daher den Hersteller (Winsoft) kontaktieren.

Mehr zu diesem Thema habe ich auf meine Anfrage bei Stackoverflow erfahren:

"Is it dangerous to use synchronize in a non-VCL application?"

http://stackoverflow.com/questions/1...cl-application

Scheint mir ein Designproblem zu sein. Wir haben auch diverse Entwicklungen welche sowohl als auch laufen.
Der Controller und alles darunter ist logischerweise identisch. Und nur im Falle eines GUI's - also beim
Start als Applikation wird Synchronize verwendet. Nämlich um die (VCL-) Anzeige zu aktualisieren.

Beim Zugriff auf VCL Komponenten kann man das leicht so machen - damit gibt es auch kein Problem - das Synchronize wird aber auch beim Aufruf von OnRxChar, OnRxTimeOut einer zugekauften Comport-Komponente verwendet - Mal sehen was winsoft.sk - der Hersteller der Comport Komponente dazu zu sagen hat...

mfg

Klaus

Zitat von taveuni:

Scheint mir ein Designproblem zu sein. Wir haben auch diverse Entwicklungen welche sowohl als auch laufen.

Verwenden diese auch Threads?

Da ein Thread nicht wissen kann, ob er in einem Service, einem Konsoleprogramm, unter OSX, Linux (Android) oder innerhalb einer VCL GUI Anwendung läuft, muss er entweder auf synchronize verzichten oder von der Anwendung 'informiert' werden, ob synchronize verwendet werden soll...

Und wie der rote Kasten mir gerade anzeigt, wird in Comport auch fleißig Synchronize verwendet

http://docwiki.embarcadero.com/Libra...eckSynchronize

Steht aber eigentlich schon in dem verlinkten stackoverflow-Artikel oben.

Zitat von Olli73:

http://docwiki.embarcadero.com/Libra...eckSynchronize

Steht aber eigentlich schon in dem verlinkten stackoverflow-Artikel oben.

CheckSynchronize ist nur notwendig, wenn man den Code, der synchronize aufruft (in einer nicht-VCL Anwendung) nicht unter eigener Kontrolle hat. (Zum Beispiel wenn man nur DCUs und nicht den Sourcecode hat.

Wenn der Thread "weiss", dass er kein synchronize braucht, ist auch CheckSynchronize nicht notwendig, sondern nur Overhead (bzw. eine Lösung für ein Problem, dass man ohne synchronize nicht hat).

synchronize ist so etwas wie das GOTO (oder with) der Delphi Threadprogrammierung. IMHO. Ok, ich verwende es in eigenem Code - aber mit einem 'if ...' davor