Ich hätte eine Designfrage zu einer neuen DLL an der ich gerade arbeite:

Dazu muss ich sagen, das ich bisher bereits länger eine einsetze die auf Basis von Postmessage arbeitet (mit eigenem Fenster im Hintergrund) und daraus Callbacks durchführt.

Die DLL hat eine reine C-Schnittstelle (damit sie aus jeder Programmierumgebung verwendet werden kann) und das soll auch so bleiben. Ich brauche sie aber u.U. auch für Linux und daher dachte ich ich setze das mit der Delphi Threading-Unterstützung um (ich hoffe wenn ich auf reine Boardmittel setze funktioniert das auch? Kann das jemand bestätigen?). Bisher habe ich meine Threads selber verwaltet und auf Delphi-Klassen komplett verzichtet.
Die DLL erlaubt es Verbindung mit externen Geräten aufzunehmen, für jedes wird dann ein Thread erzeugt, der die Kommunikation mit dem Gerät durchführt und etwaige Resultate per Callback zurückgibt.

Mit meiner reinen Delphi-Variante funktioniert das auch bereits "einigermaßen", leider muss man ja, damit die Synchronisierung funktioniert von außen im OnIdle (so mach ich das aktuell über eine exportierte Funktion) CheckSynchronize() aufrufen. Das ist für Delphi-Lösungen vermutlich akzeptabel, aber aus anderen Umgebungen heraus eventuell schwierig?

Die Fragen die ich habe:
Ist das bereits die beste Umsetzungsmöglichkeit?
Funktioniert das auch unter Linux (meine Linuxerfahrung bisher erschöpft sich an der Kommandozeile)?
Gibt es Vorschläge, wie man das verbessern/besser umsetzen kann?

Das funktioniert unter Linux grundsätzlich genauso, allerdings brauchst du eine andere Quelle für den Aufruf von CheckSynchronize, da es dort WM_IDLE nicht gibt. Das kann z.B. in einem Timer passieren.

Ansonsten funktioniert das Threading mit TThread usw. auch unter Linux.

Aber sollte CheckSynchronize vom FMX nicht auch selbst ausgeführt werden?

beim Verarbeiten von Messages, bzw. nachdem das SyncEvent TThread.Synchronize, bzw. Queue, getriggert wird.

Zitat von jaenicke:

Das funktioniert unter Linux grundsätzlich genauso, allerdings brauchst du eine andere Quelle für den Aufruf von CheckSynchronize, da es dort WM_IDLE nicht gibt. Das kann z.B. in einem Timer passieren.

Ansonsten funktioniert das Threading mit TThread usw. auch unter Linux.

Das klingt schon mal super. Linux würde ich nicht selber implementieren sondiern die .so weitergeben. Ich müsste dann in der Doku vorgeben, das für Linux ein Timer mit (200ms??) eingesetzt werden muss, der dann meine dllCheckSynchronize() funktion aufruft (und das wiederholt solange sie True zurück liefert)?

Zitat von himitsu:

Aber sollte CheckSynchronize vom FMX nicht auch selbst ausgeführt werden?

beim Verarbeiten von Messages, bzw. nachdem das SyncEvent TThread.Synchronize, bzw. Queue, getriggert wird.

Das ganze ist GUI los. Eine DLL die ein paar Funktionen zur Verfügung stellt ...
Soweit ich das bisher beobachten konnte, bleibt Queue() in einer DLL einfach hängen, wenn der Aufruf nicht erfolgt (eigen Kopie der RTL, soweit ich das verstanden habe)

Im Prinzip sieht mein Thread etwa so aus:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TDeviceThread.Execute;
begin
  while not Terminated do
  begin
    case fInQueue.PopItem(LSize, LItem) of
      wrSignaled: Begin
        // do something more with it (send/receive data)
        DoRequest(LItem); // Block till timeout or answer received
        fOutQueue.PushItem(LItem);
        Queue(DeliverItem);
      End;
      wrTimeout: Begin
        // every 200ms check if some internal handling is needed
      end;
    end
  end;
end;

Ich dachte das TThread.Synchronize/Queue innerhalb der Anwendung, in der Callback-Prozedur, welche von der DLL aus aufgerufen wird.
Da es system-unabhängig sein soll, kann darf Dieses auch nicht innerhalb der DLL gemacht werden.

Achso, ja, das muß auch hängen bleiben, selbst im Windows/VCL.
Dieses arbeitet über Messages, mit einer globalen Liste und einem globalen Event (im Windows), was nicht funktionieren kann, wenn die DLL ist eigenen globalen Listen/Objekte besitzt, da sie ohne Laufzeitpackages eine eigen Kopie der RTL besitzen.