Synchronize(), TThread und Bibliotheken

[mschnell]

was die GLib für mich in Sachen Threading zu bieten hat,

the pthread_...() Funktionen: POSIX-Kompatibel

oder aber einen großen Teil der verwendeten 3rd-party API von asynchron auf synchron umstellen. (würde ich ungern machen, da die snychrone API eventuell bald eingestellt wird und diese Lösung meine GUI blockiert)

Dann eben die synchronen 3rd-Party in einem Thread aufrufe. Dann hast Du die Synchronisation im Pascal-Code in der Hand.
-Michael

[Targion]

So mache ich das jetzt auch. Ich werde den Thread intern verwalten. Dadurch kann ich zwar keine asynchronen Funktionen erstellen, aber die nötigen Stücke laufen als eigener Thread, was den Bug, wegen dem ich dieses Theater veranstalten muss, vollständig beheben wird.
Vielen Dank für die Hilfe! In Zukunft werde ich es vielleicht doch nochmal mit asynchronen Funktionen probieren, jetzt aber erstmal nicht.
Falls jemand anderes mal das gleiche Problem hat: GLib-Mainloops können eventuell eine Lösung für's eventhandling sein.
Außerdem schreibt Michael Van Canneyt auf der FPC-Mailingliste zu dem Thema, man solle im Hauptprogramm den eigenen Threadmanager als Threadmanager für die Lib verwenden. Dabei geht dann aber die Kompatibilität zu C verloren.

Export SetThreadManager() and call it from your main application with the
threadmanager from the main application.

@mschnell: Das klingt sehr interessant. Ich werde mich darüber mal genauer informieren. (Aber ich glaube nicht, dass das unter Linux mit FPC auch so elegant geht)

[marcov]

So mache ich das jetzt auch. Ich werde den Thread intern verwalten. Dadurch kann ich zwar keine asynchronen Funktionen erstellen, aber die nötigen Stücke laufen als eigener Thread, was den Bug, wegen dem ich dieses Theater veranstalten muss, vollständig beheben wird.

Communicieren ueber named pipes oder shared mem vielleicht?

[mschnell]

Ich werde den Thread intern verwalten. Dadurch kann ich zwar keine asynchronen Funktionen erstellen,

Was ist denn da der Unterschied ? Ob die Asynchronität der Funktion im Pascal oder im C Code realisiert ist, ist im Endeffekt doch Wurscht.

-Michael

[mschnell]

@mschnell: Das klingt sehr interessant. Ich werde mich darüber mal genauer informieren. (Aber ich glaube nicht, dass das unter Linux mit FPC auch so elegant geht)

Was genau meinst Du ? "PostMessage / procedure ... message" ist in der LCL auch in Linux perfekt implementiert. "Synchronize" natürlich auch. (Beides natürlich nur innerhalb einer LCL/RTL instanz.)

Was wäre in Linux "nicht elegant" ?

-Michael

[mschnell]

Communicieren ueber named pipes oder shared mem vielleicht?

Pipes etc. sind in Linux erst 'mal nicht asynchron. Man könnte select() oder (moderner) epoll() verwenden um den Mainthread weiterlaufen zu lassen, während er auf ein pipe-Event wartet. Das ist aber für den "Normal-Lazarus-User" nicht besonders geeignet. Gibt es nicht in der RTL ub der Unit SyncOBJs mit "TEventObject.WaitFor" eine Architektur-Unabhängige Enkapsulierung für Thread-Events ?

Update: TEventObject.WaitFor kann man anscheinend nicht im Mainthread verwenden. Hier wird z.B. das umgekehrte realisiert: Mainthrfead läuft, Thrfead wartet

-Michael

[Targion]

Ich habe nochwas gefunden: glib-Asynchronous-Queues
Da meine Lib wegen PackageKit sowieso schon eine Abhängigkeit zu GLib hat, kann ich das ja mal ausprobieren.
An TEventObject habe ich noch gar nicht gedacht.... Ich glaube bald habe ich die ultimative Lösung, wenn das so weiter geht.

[mschnell]

P.S.: TEventObject ist dasselbe wie TEvent. Also verwendest Du bessert gleich TEvent.

-Michael

[marcov]

Nein, es wird emuliert.

Ich sehe keinen Unterschied zwischen "emuliert" und realisiert.

Ah. Also den gibts kein Problem, wenn dass OS selber Postmessage unterstützt. Dann ist es egal ob es mehrere LCL (also, Emulatoren) gibt.

Du kannst es gerne "emuliert" nennen, weil die ursprüngliche Dokumentation für die Funktionalität von Microsoft stammt.

Nein. es ist eine Emulation weil die von Microsoft kommender Funktionalität nicht von den native OS unterstützt ist.

(manche sagen ja auch Mono emuliert .Net )

Mono emuliert .NET was in sich selber eine virtueller OS (.NET OS) Emulation über Windows ist. Aber das ist beiseite

Mit sehr guter Performance, komplett innerhalb der LCL realisiert, verwendbar um Messages von einem Thread zum Mainthread zu schicken

Aber das ist nicht was hier spielt. Das ist von einer zweiter RTL zur primärer LCL/RTL

Da hast Du natürlich recht. zwei Runtimes/LCLs im selben Programm Ist aber auch eine recht "komische" Situation. Natürlich geht es auch nicht zwischen zwei Programmen. Hier gibt es bei Windows die Baugleiche Methodik

Programm ist ein bisschen vage hier. Prozess ist besser, aber ein Mainprogram und ein shared Lib sinds immerhin in demselben Prozess.

[mschnell]

es ist eine Emulation weil die von Microsoft kommender Funktionalität nicht von den native OS unterstützt ist.

Für den Anwendungs-Programmierer ist es egal, ob eine Funktionalität vom OS oder von der Laufzeit-Bibliothek unterstützt wird, oder ob die Heinzelmännchen aus Köln angelaufen kommen und die Bits verschieben. Wenn es mit guter Performence sauber funktioniert, kann er die Funktionalität (den von seiner Programmier-Umgebung bereitgestellten Funktionsaufruf) verwenden. Und wenn das auch noch Architektur-unabhängig 1:1 portabel ist (wie PostMessage <aber nicht SendMessage> in Lazarus) ist er happy.

PostMessage bedeutet schließlich einfach:
Schicke eine Event-Mitteilung an einen Thread dieses Programmes, der eine Event-Queue besitzt, die mit einem (Integer) Handle spezifiziert ist. Die Mitteilung besteht aus drei 32 Bit Werter (bzw. 64 Bit bei 64 Bit Systemen). Die Programmier-Umgebung stellt auf Implementierungs-abhängige Art die Event-Queue zur Verfügung. Ein Thread kannsolche Events durch das Konstrukt procedure ... Message empfangen, das als Klassen-Funktion einer mit in den "Dispatch"-Mechanismus, den die Programmier-Umgebung zur Verfügung stellt, eingebunden ist. Der notwendige Handle ist als Klassenvariable dieser Klasse (oder einer Klasse in der "Parent"-Kette) verfügbar.

(Momentane Einschränkung sowohl bei Delphi als auch bei FPC/Lazarus: die RTÖL baut nur für den Mainthread eine Event-Queue auf (das ließe sich prinzipiell leicht erweitern, für Delphi macht das z.B. "MadDHI").

Darum bin ich dabei, PostMessage (und anderes) in den "NoGUI" Widget-Type einzubauen, damit es auch auf Linux-Systeme ohne GTK oder QT läuft.

Das es in dem Sonderfall mit shared Libraries nicht funktioniert, ist schade, tut dem ganzen aber keinen Abbruch. Man könnte sich sicher eine Methodik einfallen lassen, die Event-Queues der beiden RTLs zu verbinden. Vielleicht fällt mir da ja noch was zu ein, wenn ich mit dem "NOGUI-Linux"-Projekt weiter fortgeschritten bin.

-Michael

[marcov]

es ist eine Emulation weil die von Microsoft kommender Funktionalität nicht von den native OS unterstützt ist.

Für den Anwendungs-Programmierer ist es egal, ob eine Funktionalität vom OS oder von der Laufzeit-Bibliothek unterstützt wird, oder ob die Heinzelmännchen aus Köln angelaufen kommen und die Bits verschieben.

Das ist exact das Problem in dieser Thread. Wenn das ueber die grenzen der Laufzeit hingeht, bemerkt man das. Auf Windows functioniert es dan noch immer, auf Linux nicht. Also es ist nicht egal.

[mschnell]

Wenn das ueber die grenzen der Laufzeit hingeht, bemerkt man das. Auf Windows functioniert es dan noch immer, auf Linux nicht.

Was genau funktioniert wann und in welcher Weise nicht ? Hast Du ein Beispiel ?

Gruß und Dank,
-Michael

[marcov]

Wenn das ueber die grenzen der Laufzeit hingeht, bemerkt man das. Auf Windows functioniert es dan noch immer, auf Linux nicht.

Was genau funktioniert wann und in welcher Weise nicht ? Hast Du ein Beispiel ?

Es gibt zwei postmessage queues (siehe zb gtk/gtkwinapi.inc), eine für das Mainprogram, eine fuer der shared Library, und die sind nicht gelinkt.

Mann kann natürlich versuchen diese manuell zu linken, aber dann ist dies nicht besser als jene andere manueller Methode.

[mschnell]

Entschuldigung !

Ich dachte es wäre klar, dass ich nicht von der Situation mit zwei RTLs (shared library) spreche, sondern von der Standard-Situation. mit nur einem Programm mit mehreren Threads. (Damit arbeite ich in meinen Projekten.)

Siehst Du dabei Probleme mit PostMessage in Linux ?

-Michael

[marcov]

Ich dachte es wäre klar, dass ich nicht von der Situation mit zwei RTLs (shared library) spreche, sondern von der Standard-Situation. mit nur einem Programm mit mehreren Threads. (Damit arbeite ich in meinen Projekten.)

Siehst Du dabei Probleme mit PostMessage in Linux ?

Nur wenig. Unter Linux muss der Mainschleife vielleicht etwas mehr Polling sein, aber das ist fuer normale Programme kein wirkliches Problem.