Und zu der Dummy-Variable ... sollteste dir mal die Hilfe durchlesen.
CreateThread erwartet ein Parameter. Das ist kein optionaler Wert! Somit
muss die entsprechende Prozedur, welche als Thread laufen soll, einen
LONG-Parameter haben.
Natürlich bekommen meine Threads einen Wert mit.Das geht ja auch gar nicht anders weil sonst der Syntax Check meckert.PB hat es allerdings bisher nicht gestört, das die aufgerufenen Procedures keinen Wert erwartet haben.Wenn es also so essentiell wichtig ist, dann sollte der Syntax check merken, das ich da einen Wert schicke, aber meine Procedure gar keinen entgegennimmt.Wenn ich die Procedur als solche aufrufe und dann einen Wert mitsende, merkt das PB ja auch und bringt einen Fehler beim Compile.Für so kritische Sachen wie Threads sollte das erst recht gelten.In der Hilfe ist jedenfalls so nicht die Rede davon.Und da ich meinen Procedures meistens Strings übergebe, dachte ich mir, ok die Zahl vom Thread brauch ich dann nicht, also mach ich das anders und laß die Zahl einfach weg.Es lief ja auch eine lange Zeit.
Alles andere kann zu abstürzen führen und
somit zur instabilität eines Programms beihelfen.
Wie ich festgestellt habe, muß da was dran sein.Ich habe nun alle meine Thread-Procedures damit ausgerüstet.Ob das was bringt, muß ich erst testen, was nicht so einfach ist, da die Fehler ja nicht so oft und reproduzierbar auftreten.
Und ich wiederhole gerne noch mal ... Threads sind in PB genau so
verschriehen wie in anderen Sprachen, warum ... das solltest du langsam
verstanden haben.
Mmmh...wie soll man dann Asynchronität erreichen...? Ich habe genau deshalb Threads gewählt, weil ich damit genau das erreichen kann, was ich möchte.Der Thread, der Daten einsammelt, kann nicht warten, bis der Mailer die Mail rausgesendet hat, weil er sonst in der Zeit nichts loggen könnte.Im Prinzip läufts Spitze, bin sehr zufrieden mit meinem Ergebnis...wenn da nicht diese mysteriösen Abstürze wären.Ich selber kann damit vielleicht noch leben, aber wenn ich meine Arbeit anderen zur Verfügung stellen wollte, dann wäre das kein Zustand.
Ich bin offen für neues...wenn jemand einen besseren Vorschlag hat, wie man mehrere Sachen parallel bearbeiten kann und dabei das GUI noch flüssig reagiert - dann her damit.
PB ist ein erster Linie ein "Ein-Mann-Projekt", da Fred alleine am Compiler
arbeitet. Funktionalität ist zwar höchstes gebot und zu einem hohen
Prozentsatz gegeben ... aber auch Fred ist nicht perfekt ...
Das mag aus Sicht des Programmierers so richtig sein, aber PB ist nunmal keine Freeware, sondern wird kommerziell vertrieben.Ich weiß, es liegt am unteren Ende der Preisskala und ich fühl mich so richtig wohl damit, weil es mir von der früheren Amiga Intuition Programmierung sehr vertraut vorkommt.( da hieß CreateThread CreateTask wenn ich mich recht erinnere...

).Nützt nur nix, wenn die Projekte - in die man ebenfalls viel Zeit reingesteckt hat - am Ende nicht richtig laufen bzw. crashen.
Multi-Threading ist meiner Meinung nach kein Hexenwerk - wie will man sonst 4 Kerne ausnutzen...? Programme mit hoher Anforderung an Rechenleistung wie MPEG Encoder usw. können aus mehreren Cores nur was rausholen, wenn sie mit mehreren Threads gleichzeitig rechnen.
Also sehe ich da keinen Fehler drin, Threads zu benutzen.
will sagen, in
PB kann sich zu jeder Version und somit zu praktisch jedem Release ein
Fehler einschleichen, und das betrifft alles, auch Threads.
Keine Software ist ohne Fehler.Soviel ist schonmal klar.Darum geht es aber auch gar nicht.Vielmehr hatte ich nach den Best-Practices für Thread-Verwendung gefragt.Siehe weiter oben...
Grüße
TWELVE