Non GUI Application

[mschnell]

Ich habe meine Gedanken zur Erweiterung des Sprachumfangs, der mit vorschwebt, spaßeshalber einmal zusammengefasst:



Procedure of Thread

Durch diese Maßnahme würde Lazarus/FPC zu einer Programmier-Umgebung erweitert die (wie ADA, nur besser :) ) Multithreadding in konsistenter Weise unterstützt.

– vorläufiges Konzept –

Es wird ein neues Sprachelement „of Thread“ definiert, das syntaktisch wie „of Object“ bei der Deklaration von Typen von Prozeduren und Funktionen verwendet werden kann.

Die Verwendung einer „Procedure of Thread“ oder „Function of Thread“ als Ereignis lässt beim „Feuern“ den Handler des Ereignisses im Kontext des Threads ablaufen, der die Ereignis-Variable gesetzt hat. (Solche Events sollen dan "Thread-Event" genannt werden.) Als Spezialfall wird die Funktionsweise von TThread.Synchronize reproduziert.

Im Detail bewirkt eine Element vom Typ „Procedure of Thread“ oder „Function of Thread“ folgendes:

Als Variable oder Property kann es wie ein Element „of Object“ verwendet werden, um einen Ereignis-Handler zu definieren. Bei der Zuweisung wird (wie bei „of Object“) die Adresse des Einsprung-Punktes und der aktuelle Self-Pointer gespeichert. Zusätzlich wird noch eine Kennung für den aktuell laufenden Thread gespeichert. Eine Variable vom Typ „of Thread“ besteht also (vermutlich) aus drei Doppelworten.

Wird eine Funktion oder Prozedur vom Typ „of Thread“ aufgerufen (i. A. unter Verwendung einer „of Thread“ - Variablen) geschieht folgendes:

Ist der aktuelle Thread gleich des in der Variablen gespeicherten Threads (oder wird eine „of Thread“ Funktion/Prozedur direkt – ohne Verwendung einer Event-Variablen – aufgerufen), wird der Event-Handler als normale Funktion aufgerufen.

Anderenfalls wird eine Struktur angelegt, die die Aktual-Parameter repräsentiert (hier wird verfahren wie bei RPC-Mechanismen üblich). Diverse Probleme sind hier zu beachten:

- es wird eine neue Aufrufkonvention („RPC“ oder so ähnlich) verwendet, also nicht „Register“ „RPCCall“ u.s.w.

- Bei dem Namen nach übergebene Const- und Var- Parameter und Objekttypen wird vermutlich einfach der Pointer verwendet.

- Es kann natürlich sein, dass vor der Bearbeitung durch den anderen Thread die Struktur bereits gefreed ist. Idealer Weise sollte (bei Bedarf) durch einen reference counting Mechanismus sichergestellt werden, dass so etwas nicht passiert. Vielleicht sollten nur reference counted Typen (wie String und Interface und vielleicht ein neuer automatischer Typ, der reference counted 8/16/32/64 Bit Numerics und Floating Points darstellen kann) zugelassen werden (bei teilweise automatischer Konvertierung von Standard-Typen: Zahl -> reference counted Zahl, Klasse -> Interface).

- Pointer auf lokale (Stack-) Variablen sind verboten (sollten explizite Pointer erlaubt sein ?).

- Variants sind vermutlich reference counted ????

- vielleicht ist die „In“ und „Out“ Syntax für Parameter sinnvoller als zu versuchen „Value“, Const, und Var -Parameter automatisch zu behandeln.

- Die Übergabe des Funktionswertes erfolgt wie bei einem Var-Parameter. Die Kennung ob eine Funktionswert verlangt wird, wird bei Funktionen als zusätzlicher Parameter in der RPC-Struktur gehalten. Weiteres zu Funktions-Rückgabe-Werte siehe unten.

Wenn beim Aufruf ein Funktionswert verlangt wird, wird der aufrufende Thread angehalten bis der gerufene Thread das Ereignis abgearbeitet hat (analog der „Synchronize“ - Methode von TThread). (Das kann leicht durch eine Semaphore realisiert werden.) Da der rufende Thread blockiert ist, wird die blockierende Ressource als zusätzlicher Parameter an den aufgerufenen Thread übergeben. Bei Prozeduren und wenn eine Funktion wie eine Prozedur (ohne „:=“) aufgerufen wird, läuft der aufgerufene Thread parallel mit dem aufrufenden. (Wenn als ein Wert aus einem parallel laufenden Thread zurückgegeben werden soll geht das nur mit einem Var-oder „Out“ Parameter.)

Es wird eine Message generiert und an den aufzurufenden Thread geschickt (hierzu muss dieser Thread natürlich mit einer Message-Queue ausgestattet sein ). Die Message enthält die Referenz auf die RPC-Parameter-Struktur.

wird die Message aus der Queue bearbeitet, extrahiert der empfangende Thread die Parameter aus der Parameterstruktur und ruft den Usercode des Event-Handlers auf.

Nach Rückkehr aus dem User-Code wird (falls angefordert) die Ressource freigegeben, die den aufrufenden Thread blockiert.

Frage: ist es sinnvoll eine Möglichkeit zu schaffen, einen anderen als den aktuellen Thread als aufzurufenden Thread zu vermerken ? Die Syntax hierzu müsste vermutlich stark von der Standard-Syntax abweichen.

Es wäre schön, die Definition und den Start der zusätzlichen Threads nicht im User-Code machen zu müssen. Hier bietet sich der Objekt-Quelltext an, um analog zu „Application.Init“ und „Application.Run“ für alle vordefinierten Threads einen Block erzeugen der (für x = 1,...n) in etwas so aussehen könnte:

Code: Alles auswählen

ApplicationThreadx := TApplicationThread.create;
ApplicationThreadx.Init;              // Falls das notwendig ist     
ApplicationThreadx.Run;

Die IDE könnte diesen Code erzeugen und den Basiscode eines primären Execute-Events für alle Threads (in einer separaten Unit oder auch im Projekt-Quelltext) vorgeben:

Code: Alles auswählen

Procedure ApplicationThreadx.Execute;
begin
// place the code for starting your Application Thread here
end;

Es ist natürlich auch möglich, im User-Code zusätzliche ApplicationThreads zu instanziieren und zu starten. Diese können dann im Execute-Event ThreadEvents anmelden, um von anderen Threads aufgerufen zu werden.

Ich freue mich über weitere Anregungen.
-Michael

[schnullerbacke]

Nun sind aber Prozesse und Threads zur Compile-Zeit nicht existend, wie willst du also das notwendige Handling im Compiler verankern?

Das könnte ja nur über einen neuen Datentyp (TProcess, TThread) möglich sein. Die Folge ist ein krätiges Stackhandling, denn nur dort ließen sich die Rücksprungpunkte finden.

Ich denke, da wäre es einfacher ein entsprechendes Objekt z.V. zu stellen ohne deshalb die Sprache zu befrachten. Das ist letztlich Low-Level-Programmierung und wurde für TurboPascal alles schon gemacht.

Im Übrigten denke ich, das man nicht an die Threads gehen sollte, sondern besser über TProcess gehen sollte. Threads sind eine Sonderform von Prozess die es eigentlich nur in Windoof's gibt. Linux macht das mit echten Prozessen und lebt sehr gut damit.

[mschnell]

Zunächst lassen sich "ApplicationThreads" auch ohne Spracherweiterung einfach als Objekte definieren und verwenden ("Application" (als Repräsentatiuon des GUI Main Threads) ist auch in der Sprache selbst nicht definiert, sondern nur in der Library (und der IDE) ).

Wie im "Konzept" beschrieben wird für eine "voll integrierte" Lösung als Spracherweiterung nur "of Thread" benötigt. Die Datentypen (TApplicationThread) sind genauso wenig "Sprachumfang" (also dem Compiler bekannt) wie bisher TApplication oder TThread.

Threads (auch normale TThreads) belasten immer das Memory für Stacks, da ja jeder Thread seinen eigenen unabhängigen Stack hat.

Threads gibt es durchaus nicht nur in Windows, sondern in der Unix-Welt seit Ur-Zeiten, bevor irgendjemand an Windows auch nur gedacht hat, in der Thread-Library und sie sind im Posix-Standard Betriebssystem-unhabhängig definiert. Der Linux-Kernel kennt Threads seit Version 2.6. Vorher hat die "pthread"-Library Threads aus Betriebssystem-Prozessen gebaut (ein Programm mit insgesamt n Threads , n>1), brauchte n+1 Linux-Prozesse, einen zur Verwaltung). Mit Kernel 2.6 ist das schöner, da werden Threads an prozesse angehängt. In Linux (2.4 und erst recht 2.6) ist das Thread-Handling sehr viel effizienter als in Windows. Allerdings ist der Unterschied nicht so eklatant wie beim Prozess-Handling, das in Windows ganz katastrophal ineffektiv ist.

-Michael

[Christian]

Ich find das konzept so schon richtig. Es liegt schliesslich in der Natur von Pascal dem Programmierer Arbeit abzunehmen und mit komplexeren problemen nicht im regen stehn zu lassen. Die Stringverarbeitung ist ja auch komplett intigriert und das ergebnis ist das kaum Sicherheitslücken aus der Stringverarbeitung in Pascal existieren in C haben sie da heut noch massive Probleme.

Da Programme in zukunft häufiger auf thread lösungen zurückgreifen sollten wäre das schon eine sehr schöne sache.

[schnullerbacke]

@Christian

Nullterminierte Strings sind ja auch keine einfache Sache. Ich hab mal ne kleine StringUtils für TurboPascal für Windows gebastelt weil da zwar die Nullterminierten existierten aber eben keine Behandlungsmethoden (pos, delete, usw.). Das war ne Menge Testerei bis die liefen.

Die Stringverarbeitung bei Pascal beruht zum größten Teil auf der Definition von Wirth, der hatte bewußt auf intelligente Stringverarbeitung gesetzt, weil dem einfach klar war, daß das größeren Raum bei den Programmen einnehmen wird.

Im Übrigen läßt die Definition von "Programmiersprache" als solches eigentlich keinen Raum für die Integration von Prozeduren und Funktionen. Die sind für sich gesehen in allgemeiner Form in der Syntax vorhanden. Was nichts weiter heißt, als das man per Modul so ziemlich alles in eine Umgebung bauen kann. Selbst die OOP hätte man ohne Änderungen am Compiler machen können. Ein Spracherweiterung hätte es dafür nicht gebraucht.

Entscheidender dürfte aber sein, das ein Thread oder ein Prozess nicht eine einzelne Methode wie bei "of Object" ist, dabei handelt es sich um eine komplexe Struktur, was die Integration in den Sprachumfang bereits ausschließt. Und es hindert dich ja auch niemand, einen Prozedur- oder Funktions-Typ als "of Object" zu deklarieren und diesen in deinen Objekten zu verwenden. Das hatte ich irgendwo im Forum mal als Beispiel gezeigt. Damit kann man mehrer Threads ohne Probleme an ein Objekt binden, allerdings muß das in der Methode dann mit CriticalSection abgesichert werden, damit sich die Threads nicht gegenseitig ins Gehege kommen.

Dann hindert uns ja auch niemand daran, eine globale Threadliste (TList) im Programm zu vereinbaren und jeden Thread (das ist schon ein Pointer) dort einzutragen. Da nun aber Pointer immer eindeutig sind, hat man also die Kennung schon, was einen nicht hindert dem Thread noch eine eindeutige Nummer zu verpassen.

Was man also letztlich bräuchte ist ein von TList abgeleitetes Objekt, das den speziellen Fall der Threads behandelt, das könnte man zum Gegenstand der Umgebung machen und hat damit das Thema erschlagen ohne die Sprache zu erweitern (Create von TThread trägt den Thread automatisch in die Liste ein --> eindeutige Kennung über den Pointer). Das Listen-Objekt könnte dann auch zur Synchronisierung der Threads die entsprechenden Methoden z.V. stellen. Eventuell muß man dann das TThread-Objekt noch etwas erweitern (ThreadSynchronize-Methode) und noch einen Datenchannel für die Datenübertragung zwischen den Threads einbauen.

Auf Kurzform gebracht, es ist bereits alles da was man braucht. Und ein paar Geheimnisse sollten wir schon noch für uns behalten, sonst kommen die Juristen, Kaufleute oder noch schlimmer Politiker noch auf die Idee, sie könnten programmieren. Das sollten wir tunlichst verhindern, die bauen auch so schon genug Mist.

[Christian]

Du musst immer aus allem eine Wissenschaft machen.
Wenn du das was du da oben geschrieben hast alles ernst meinst was willst du dann hier in diesem Fall ist C die richtige Sprache für dich oder besser Assembler da hast du Minimalsprachen in denen du alles zu fuss machen kannst.

Sicher lässt sich das auch ohne spracherweiterung lösen, aber stell dir mal eine Spracherweiterung vor in der du sagen kannst das für diese procedure ein thread angelegt werden soll. den du mit speziellen befehlen steuern kannst und der compiler die syncronisation verwaltet. Das wäre ein enormer vorteil, da die thread programmierung sehr vereinfacht wird. Deadlocks gehören quasi der vergangeheit an da der compiler das zur compile zeit erkennt und nen compilerfehler erzeugt.

[schnullerbacke]

@Christian

Das Problem ist mehr, das ich in den Jahren so einige angebliche Verbesserungen gesehen habe, die sich dann sehr schnell als Einschränkung entpuppt haben. Das Ende vom Lied war meistens selber was bauen um den Einschränkungen zu entgehen.

Und C/C++ bietet nur unerheblich mehr als PASCAL und ist dafür auch fehleranfälliger. Wenn ich denn so ein Purist wäre, würde ich gleich Smalltalk nehmen und wäre an den Ursprüngen der OOP.

[Christian]

Ich bin kein fan davon solche Sätze ohne Background loszulassen.
Mir fallen wenig Pascal Spracherweiterungen ein die nach hinten losgegangen sind.

[mschnell]

Bei der vorgeschlagenen Spracherweiterung ("of Thread") geht es nicht darum die Threads zu erzeugen und zu löschen etc (das geht jetzt auch schon), sondern die Verwendung der Threads (ihnen also Aufgaben zuzuteilen) Object-Pascal-Typisch (also Event-orientiert) und Benutzerfreundlich zu gestalten.

-Michael

[mschnell]

Im Übrigten denke ich, das man nicht an die Threads gehen sollte, sondern besser über TProcess gehen sollte. Threads sind eine Sonderform von Prozess

Von einer Programmiersprache aus gesehen ist der Unterschied zwischen Threads und Prozessen, dass man bei Threads gemeinsame von der Sprache verwaltete Ressourcen (Memory, offene Dateien etc.) verwenden kann und bei Prozessen nicht. In Delphi können Threads gemeinsame Objekte verwenden (z.B. TThreadList ist extra dafür gebaut). Prozesse können Daten nur über Betriebssystem-Mittel austauschen (z.B. shared Memory, named Pipes, TCP/IP, ... ). Innerhalb eines Delphi-Programms sind Threads deshalb hochgradig sinnvoll.

-Michael

[schnullerbacke]

Ich bin kein fan davon solche Sätze ohne Background loszulassen.
Mir fallen wenig Pascal Spracherweiterungen ein die nach hinten losgegangen sind.

Na da legen wir mal los.

Erweiterte Syntax {$X+} hätte man sich schenken können. Da ObjectPascal und Pascal eh schon 2 Paar Schuhe sind hätte man auch gleich hergehen können und das Schlüsselwort "function" fallen lassen und stattdessen lieber "procedure" um einen Ergebnistyp erweitern können. Dann gebe es eben beides, Prozeduren mit und ohne Rückgabewert (Modula 2 läßt grüßen}.

Die Einführung von "message" hätte man dann zum Anlass nehmen müssen, in Pascal selbst ein "Message-System" zu implementieren, das dann für alle Objekte unabhängig von Windoof's gilt. Den Unfug haben wir Borland's Liebesheirat mit Microsoft zu verdanken.

In Delphi (oder besser BDS für .NET) hat Borland inzwischen die Variants wieder fallen lassen und setzt voll auf OLEVariant, das kann aber nur die COM-Schnittstelle von Windoof's bedienen. Ich hoffe schwer, das die FPC-Leute diesen Schwachsinn nicht auch noch nachvollziehen.

Sollen sich doch die Borländer selber vom Sockel stoßen, das haben die schonmal geschafft, nachdem sie erst die "Sau haben fiegen lassen" und sich dann die DBase-Leute gekauft hatten. Damals ging bei denen offensichtlich auch schon jede Vernunft baden und die Qualität von Software, Service und Dokumentation ging den Bach runter. Dafür aber die Preise rauf.

Der Idealfall wäre ohnehin eine neue Programmiersprache, die so einfach wie C/C++, Pascal oder Modula 2 ist und die besten Konzepte von allen 3en vereint. Man könnte auch noch Anleihen bei Algol und Fortran nehmen, da gibt es es auch so einige "Schmankerl" die nicht schlecht wären. Z.B. die Initialisierung von Variablen in einer Kette:

A=B=C=D=E= 500;

Wenn sich dann die Sprache noch vollständig als reguläre Ausdrücke beschreiben ließe wäre des Programmieres Glück vollständig (von if ... then ... else mal abgesehen (Pumping-Lemma)). Die Sahnehaube wäre dann noch SQL a la COBOL als Teil der Umgebung, unabhängig von einem bestimmten SQL-Server, dann wäre der Fall richtig rund.

[mschnell]

Die Einführung von "message" hätte man dann zum Anlass nehmen müssen..

.. den Event-Aufruf Mechanismus Betriebssystem unabhängig zu machen.

procedure....message ist bereits Betriebssystem-unabhängig.

Wie Messages senden an den Mainthread Betriebssystem-unabhängig geht, weiß ich noch nicht. In forms.pp gibt es eine Funktion SendApplicationMsg, und in lclprog eine Funktion SendApplicationMessage und in controls.pp eine Funktion SendAppMessage die anscheinend alle für Windows und Linux erzeugt werden (und im Endeffekt SendApplicationMsg aufrufen).

SendAppMessage wird anscheinend nirgendwo aufgerufen. Ist also wohl für den User gedacht.

Der Gedanke geht jedenfalls in genau die Richtung, die ich auch im Sinn habe. Ich möchte aber weiter gehen und die "Message" verschleiern und dafür das bereits vorhandene Konstrukt der Delhi-Events anbieten.

Der Idealfall wäre ohnehin eine neue Programmiersprache, die so einfach wie C/C++, Pascal oder Modula 2 ist und die besten Konzepte von allen 3en vereint.

Das hat man doch mit C# und auch mit Chrome schon versucht, mit immerhin kommerziellem Erfolg

-Michael

[Christian]

Genau, das was du da beschreibst ist C#.

@schnuller aus deinen ausführungen ersehe ich nur einen Ansatz. und der ist nur noch proceduren zu haben, sicherlich nicht ganz dumm aber jeglicher bestehende code würde inkompatibel. Und so schlimm find ich das nicht das konzept macht zwar wenig sinn aber stören tuts auch nicht warum also eine änderung ?!.

Zum Message system stimm ich mschnell zu. Und weiter konnt ich kein "fehlgeschlagenes Konzept" in deinem Ausführungen finden.

[schnullerbacke]

@Christian

Aber mit einem gefährlichen Unterschied, in c gibt es so gut wie keine saubere Typ-Prüfung, das hat Pascal c entscheidend voraus. Ein großer Teil möglicher Fehler entfällt damit von vornherein. Meine Idee bringt Pascal dann mehr in die Nähe von Modula 2, die vom Konzept her fast wie Pascal ist aber mit dem Vorteil eindeutig auch BS programmieren zu können.

Und dem Scanner beizubringen in älterem Code noch vorhandene Schlüsselwörter "function" durch "procedure" zu ersetzen wäre wahrlich kein Problem. Ich würde sogar noch einen Schritt weitergehen und das Ganze gleich "method" nennen, dann wären wir direkt bei OOP gelandet und das würde auch am ehesten dem entsprechen, was das ding macht.

Bei der Renovierung könnte man dann auch gleich noch über "repeat" und "while" nachdenken. Mit etwas Geschick kann man eins von beiden ebenfalls weglassen. Denkbar wäre:

repeat {expression}

end;

oder:

repeat

until {expression};

In Pascal fehlen mir dann gelegentlich noch ein paar echte Mengen-Operatoren, sowas findet sich dann wieder in Algol. Das müßte nach so vielen Jahren eigentlich auch längst Gegenstand der Sprache sein. Dann könnte man die allseits beliebte "Ostereier-Rechnerei" auch gleich direkt machen, da käme dann "friend" von C/C++ ins Spiel.

[Christian]

Wir haben ja auch nicht von C sondern C# geredet und da gibts ne recht saubere typführung.
Aber wenn du ne neue Programmiersprache willst bau sie doch