Private / Public / Threads / Errorsys

[AUGE_OHR]

hi,

ich habe nur noch paar "globale" PUBLIC wie "zPATH" die ich beim
starten aus der Init belege.

nun bekomme ich ab und zu solche Meldungen :

oError:args :
-> NIL
oError:canDefault : N
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Unbekannte Variable
oError:filename :
oError:genCode : 22
oError:operation : zPath
oError:osCode : 0
oError:severity : 2
oError:subCode : 2000
oError:subSystem : BASE
oError:thread : 4
oError:tries : 1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------

Called from OPENCHINA(867)
Called from AABGANG(262)
Called from ABTHREAD3(5765)
Called from ABTHREAD2(4067)
------------------------------------------------------------------------------
Thread 4
------------------------------------------------------------------------------
{1, 444, 4025, "ABTHREAD1", thread}
{3, 960, NIL, NIL, thread}
{4, 1164, 544, "ERRORLOG", thread}
-----------------------------------------------

aber irgendwie kann das nicht sein den zPATH ist PUBLIC ...

wie man nun sehen kann bin ich im Thread Nummer 4 d.h. ich habe aus
dem Thread wieder einen neuen Thread gestartet. Es funktioniert auch
alles wenn ich es teste oder mir das im Debugger ansehe ...

sowas ähnliches habe ich auch ab und zu mit der PUBLIC ID_USER in der
Errorsys wenn ich einen Fehler habe in einem Thread der von einem
anderen Thread aufgerufen wurde.

was könnte also der Grund sein das ich in einem Thread, der von einem
anderen Thread aufgerufen wird, auf einmal mein PUBLIC nicht
mehr "sehen" kann ?

Nachtrag : Ich denke gerade
was passiert eigendlich wenn man in jedem Thread die Init mit den
PUBLIC nochmals aufruft ? ... die änderen sich ja eigendlich nicht ...

[Martin Altmann]

Hallo Jimmy,

Nachtrag : Ich denke gerade
was passiert eigendlich wenn man in jedem Thread die Init mit den
PUBLIC nochmals aufruft ? ... die änderen sich ja eigendlich nicht ...

Bingo - genau das, was Du fürchtest aber nicht glauben willst, passiert

Viele Grüße,
Martin

[brandelh]

Hi,

ich habe einige unabhängige Tasks in Threads ausgelagert, grundsätzlich bin ich in meinen Programmen aber eher sparsam mit eigenen Threads.

Was ich jedoch gelernt habe ist, dass man NIE weiß, welcher aktive Thread wann bzw. in welcher Reihenfolge auf eine Variable zugreift.

Deine PUBLIC Vars sind ok, solange diese EINMALIG im MAIN (oder davor) initialisiert und danach nur noch gelesen werden. Als Zustandsanzeiger könnte man sie genau dann verwenden, wenn der Zustand des Programmes gesteuert werden soll, z.B. nur ein Thread darf zu einer Zeit auf den Drucker zugreifen oder in diese Datei schreiben, wobei dafür mit dem Beispiel der Kaffeemaschine eine (bessere) andere Vorgehensweise über signale empfohlen wird.

Was auf keinen Fall gut gehen kann ist dass je Thread der Zustand angepasst wird und sich mehrere diese public dann teilen, das muss irgendwann zu Fehlern führen. Wenn man sowas machen will, muss man sich threadlocale Variablen schaffen.

Insgesamt gesehen ist die Syncronisation von Threads nicht einfach. Man denke an mögliche deadlocks etc. und wohl auch eine enorme Bremse (alle Threads warten bis einer bereit ist ...). Ich persönlich nutze Threads meist nur dann, wenn die Aufgabe wirklich unabhängig ist (z.B. Drucken).

[AUGE_OHR]

Hi,

Was ich jedoch gelernt habe ist, dass man NIE weiß, welcher aktive Thread wann bzw. in welcher Reihenfolge auf eine Variable zugreift.

Deine PUBLIC Vars sind ok, solange diese EINMALIG im MAIN (oder davor) initialisiert und danach nur noch gelesen werden.

Was auf keinen Fall gut gehen kann ist dass je Thread der Zustand angepasst wird und sich mehrere diese public dann teilen, das muss irgendwann zu Fehlern führen. Wenn man sowas machen will, muss man sich threadlocale Variablen schaffen.

sorry nur noch mal zum Verständniss: Die PUBLIC Variabeln werden
aus einer INI Datei gefüttert d.h. "read only" da sie im Programm nicht
verändert werden. "zPATH" ist nun der "PATH" zum Server und wird
jedesmal beim öffnen von DBF Dateien benötigt und ist eigendlich auch
immer "zu sehen" ... nur bei solchen Thread ruft Thread ruft Thread etc.
kommt "abundzu" mal das Problem zu Tage sodas ich es nicht nachvoll-
ziehen kann warum dann und nicht vorher oder nacher.

ich habe sogar mal einen extra Thread laufen lassen der alle Minute
die INI liest und die mit den PUBLIC vergleicht und "schreien" sollte
wenn was nicht stimmt ... es stimmt immer ...

noch jemand eine Idee ?

[Martin Altmann]

Jimmy,
Du hast doch sicherlich vor dem Lesen der INI-Datei eine Zeile

Code: Alles auswählen

public zPATH

oder nicht?
Damit ist die Variable zPATH definiert, aber NIL

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Du hast doch sicherlich vor dem Lesen der INI-Datei eine Zeile

Code: Alles auswählen

public zPATH

oder nicht?
Damit ist die Variable zPATH definiert, aber NIL

also ich habe sie in der MAIN nach meinen LOCAL definiert von wo aus
dann die ReadINI() aufgerufen wird um die PUBLIC zu füllen. Das ganze
muss auch vor dem Login passieren den die User DBF liegt auf dem
Server auf den zPATH zeigt.

Im Logfile sieht man ja die geöffneten DBF Dateien die ich "Sekunden
vorher" geöffnet bekam. Die ARTIKEL.DBF ist schon geöffnet und nun
sollte in OpenChina() die "chinesische" DBF geöffnet werden und da
"kennt" er nun auf einmal zPATH nicht mehr ... ?

wie schon gesagt in mein Problem das ich es nicht simulieren kann denn
eigendlich sind die PUBLIC immer da ... und trotzdem passiert es

[Martin Altmann]

Hallo Jimmy,
er kennt deine zPATH schon - sie ist aber NIL!!!
Wenn ich das richtig verstehe, liest Du die Variabel in jedem Thread neu ein.
Wozu eigentlich, wenn sie Threadübergreifend immer gleich sein soll?
Und wenn Du sie in jedem Thread neu einliest, wirst Du sie ja auch in jedem Thread neu deklarieren als public (so habe ich das verstanden).
Und genau in dem Fall ist sie wieder so lange undefiniert, bis Du ihr den Wert aus der INI (erneut) zuweist!!!

Viele Grüße,
Martin

[brandelh]

Hallo Jimmy,
er kennt deine zPATH schon - sie ist aber NIL!!!
Wenn ich das richtig verstehe, liest Du die Variabel in jedem Thread neu ein.

also ich habe ihn so verstanden, dass das einmalig im MAIN VOR den Threads geschieht.

[Tom]

Ich lese ebenfalls INI-Daten (eigentlich sogar einen ziemlich umfangreichen Set von Voreinstellungen) in Publics, die ich beim Programmstart einmalig definiere (PUBLIC lKannDasUndDas := .F., cMeinPfad := '' usw.). Das läuft mit x-und-neunzig Threads total problemlos. Einige Einstellungen können auch während des Programmlaufs geändert werden, dann werden die aktuellen nochmals eingelesen, die neue Einstellung wird gesetzt und gleich im Anschluss wird wieder durchgeschrieben. Wie gesagt, tonnenweise Threads und keine Probleme.

Kann es sein, dass Deine INI beim Wiedereinlesen gelegentlich einfach nicht gefunden wird?

[AUGE_OHR]

hi,

er kennt deine zPATH schon - sie ist aber NIL!!!

... ja aber nur im Errorlog

Wenn ich das richtig verstehe, liest Du die Variabel in jedem Thread neu ein.

NEIN ! Der Nachtrag war vielmehr eine Idee wobei ich die immer nur
"füllen" und niemals declarien würde. Wenn er dann aus irgend einem
Grund nicht weiss das es eine PUBLIC ist dann müsste er ja eine Private
daraus machen und auch die "sollte" dann bis in die Errorsys "wirken".

Ich gehe wirklich nicht von einem Programmier Fehler aus, den dazu ist
der Code "zu kurz" in der NET_USE() / OpenChina() / Errorsys.

... und es passiert nie mit den "Farben" welche ich ebenfalls noch in
PUBLIC speichere.

ausser bei zPATH hab ich es ja "auch abundzu" mit ID_USER. Der Witz
ist nun das ich in meiner ErrorSys auch ID_VERSION, ID_NET etc. habe
und die auch bekomme obwohl er "abundzu" meint das ihm ID_USER
unbekannt sei ... wieso hab ich die "anderen ID_*" PUBLIC Variablen
aber nicht den Usernamen der erst beim Logout per gelöscht wird ?

Es passiert also nicht mit allen PUBLIC, aber alle PUBLIC werden nur
in der einen Routine gefüllt (ok Farben, Drucker etc. können vom User
geändert werden aber mit denen gab es noch nie Probleme )

Meisten hab ich die ID_USER noch kurz vorher im Logbuch stehen das
der User den Thread starten will mit Datum und Uhrzeit und dann im
gestarteten Thread "kennt" er die PUBLIC nicht mehr ... ?

ich habe auf jeden Fall keine weiter Idee wie ich das abfangen könnte,
denn mit dem BUG werde ich wohl leben müssen bis ich ein Sample
hinbekomme wo es nicht nur "abundzu" passiert.

[brandelh]

Nachtrag : Ich denke gerade
was passiert eigendlich wenn man in jedem Thread die Init mit den
PUBLIC nochmals aufruft ? ... die änderen sich ja eigendlich nicht ...

oouups, da lese ich ja gerade was anderes wie weiter vorne 'einmalig in der main' .... ja was nun ?

Aber daran kann es wirklich nicht liegen, denn die Fehlermeldung 'Unbekannte Variable' kommt nicht wenn PUBLIC ... durchlaufen wurde. Egal ob der Wert NIL ist oder etwas anderes, ein Problem mit dem falschen Zustand würde eine Fehlermeldung über einen falschen Datentyp haben, aber doch nicht 'Unbekannte Variable' ... sehr seltsam.

Vor kurzem hatte ich in einem Programm mehrere verschachtelte
#IF / #ENDIF mit #define SCHALTER etc. steuern wollen und plötzlich läßt sich der Quellcode nicht mehr compilieren (error 0,0 Line too long ...) ich habe es als PDR eingeschickt, aber bis jetzt noch keine Bestätigungsemail erhalten - vielleicht haben sie die ja auch abgeschaltet.

Es gibt einfach seltsame Dinge hier. Sind eigentlich Funktionen Thread-lokal ?

Ich speichere solche Variablen entweder in einem STATIC Array in einer Funktion oder als Membervariablen in einer Klasse. Publics habe ich komplett entfernt.

[Juergen]

Hallo ,

ich deklariere PUBLIC-Variable nur im Hauptprogramm,
welches die einzelnen Threads aufruft.

In den Threads benutze ich PRIVATE- und LOCAL-Variable.
Ich verändere keine PUBLIC-Variable aus einem
Thread heraus.

Die PRIVATE-Variable werden ja nach Verlassen
des Prozesses automatisch gelöscht.

Läuft schon Jahre ohne Probleme.

Gruß

Jürgen

[Manfred]

Hi,

ich muß jetzt einmal eine vielleicht recht naive Frage stellen. Ich habe den Thread auch in den Newsgroups verfolgt.

Was spricht denn dagegen, EIN PUBLIC Objekt zu erstellen und da die ganzen Vars als Membervar unterzubringen? Das Objekt ist überall erreichbar und die Vars dann auch.

Klärt mich auf, wenn ich auf dem Holzweg wandele..

[stevie]

Hi,

ich muß jetzt einmal eine vielleicht recht naive Frage stellen. Ich habe den Thread auch in den Newsgroups verfolgt.

Was spricht denn dagegen, EIN PUBLIC Objekt zu erstellen und da die ganzen Vars als Membervar unterzubringen? Das Objekt ist überall erreichbar und die Vars dann auch.

Klärt mich auf, wenn ich auf dem Holzweg wandele..

Wir machen das auch so.
Eine Klasse, die sämtliche Public-Variablen in sich vereint und als ein Object public vorhanden ist. Macht sich vor allem dann gut, wenn die globalen Daten in ner xpf für den nächsten Start gesichert werden müssen.

[AUGE_OHR]

hi,

Was spricht denn dagegen, EIN PUBLIC Objekt zu erstellen und da die ganzen Vars als Membervar unterzubringen? Das Objekt ist überall erreichbar und die Vars dann auch.

nichts ... ausser das es auch eine PUBLIC ist

Ich habe eigendlich soweit alle PUBLIC / PRIVATE die ich früher hatte
in ein Array System gebracht nur eben die paar ID_* und zPATH nicht.

Hannes Ziegler hatte mir die selbe Idee wie folgt vorgeschlagen:

> *** snip ***
> #xtranslate mARTNR => ::Stack\[::nDim,1]
>
> ...
> @x,y GET mARTNR
>
> .or.
>
> oSLE:datalink := VarBlock(@mARTNR)

You are in an excellent situation to reduce your PUBLIC variables:

<!-- -->
#xtrans mARTNR => globalVars:mARTNR

PROC MAIN
PUBLIC globalVars := HashTable()

globalVars:mARTNR := "my value"
...
RETURN
<!-- -->

The fact that your #xtrans directive is resolved to "self:Stack" makes the
HashTable() approach very promising. Self receives a message and
HasTable receives a message. There shouldn't be any performance hit in
changing to HashTable.

was Hannes unter Hashtable versteht nenne ich einfach nur "Stack" und
ich verwende ja auch ::nDim für MDI was ich auch für Threads benutzten
könnte.

Der Unterschied ist jedoch das mein Array ::Stack eine STATIC ist die sich
ein einem externen PRG befindet und (noch) kein Object ist.



... aber noch mal zurück zu PUBLIC / Thread / Thread. Ich habe auch im
Alaska Forum einen Thread geöffnet und darin beschrieben was ich zu
wissen meine:

1.) passiert nicht unter "fullGUI" sondern nur bei meinen Cl*pper/Hybrid
Anwendungen. Dort mache ich ständig die DBF zu "nach Gebrauch" sodas
ich die dann wieder öffnen muss.

2.) passiert nur wenn ich einen Thread aus einem Thread ... aufrufe.

3.) habe es mit PUBLIC und PRIVATE versucht. Beide jeweils in MAIN
declariet und einmalig gefüllt.

4.) sowohl LOCAL als auch Netzwerk

5.) passiert meistens Montags ( besinders viel Stress ? )

6.) OS() immer XP (sp2/sp3) aber nie W2K. Win98 ist nicht mehr im
Einsatz ebensowenig wie VISTA

[Manfred]

Hi,

dann habe ich das falsch verstanden. Ich dachte Du wolltest die Publics nur in möglichst geringen Mengen verarzten. Das sie komplett weg sollten, hatte ich nicht gedeutet, oder komplett überlesen.

[AUGE_OHR]

moin,

dann habe ich das falsch verstanden. Ich dachte Du wolltest die Publics nur in möglichst geringen Mengen verarzten. Das sie komplett weg sollten, hatte ich nicht gedeutet, oder komplett überlesen.

naja wenn die PUBLIC bei meiner Konstellation Probleme machen wird
es wohl egal sein ob Memvar, Object oder irgendwas anderes also muss
die "ganz weg" ... es sein den ich bekomme raus warum es bei mir "abund
zu" passiert.

[AUGE_OHR]

hi,

------------------------------------------------------------------------------
ERROR LOG of MEZI Ver.x2.111f "C:\YIUIMEX\XPPYIU.EXE" Date: 05.08.08 16:22:48

Xbase++ version : Xbase++ (R) Version 1.90.331
Operating system : Windows 2000 05.00 Build 02195 Service Pack 4
Memory (RAM_AVAIL) : 747.52 of 1014.78 MB
DiskSpace C: : 1786.37 MB
Alias() : leer
Recno() : leer
Found() : NO
NetError() : NO
Select() : 1
IndexOrd() : 0
WorkSpaceList :
------------------------------------------------------------------------------
ASCOM10.DLL : Xbase++ Runtime DLL, Hotfix Rollup #19 for Xbase++ 1.90.331
ASCOM10C.DLL : 1.90.0331 Xbase++ Runtime DLL Hotfix Rollup #16
ASRDBC10.DLL : 1.90.0331 Xbase++ Runtime DLL
CDXDBE.DLL : 1.90.0331 Xbase++ Runtime DLL
Cmbr13.dll : 1.90.0331 combit Data Browser Control
Cmct13.dll : 13,3,0,0 combit Custom Controls
cmdw13.dll : 13,2,0,0 combit Multiformat Drawing Manager
cmll13.dll : 13,0,0,0 combit List & Label Reporting Engine
cmls13.dll : 13,5,0,0 combit List & Label Storage API and Preview Control
cmpr13.dll : 13,3,0,0 combit Hierarchical Profile Manager
Cmut13.dll : 13,0,0,0 combit Utility Functions
DbfDbe.dll : 13,3,0,0 Xbase++ Runtime DLL
FoxDbe.dll : 1.90.0331 Xbase++ Runtime DLL
NTXDBE.DLL : 1.90.0331 Xbase++ Runtime DLL
XppDbgc.dll : 1.90.0331 Xbase++ Runtime DLL
XppNat.dll : 1.90.0331 Xbase++ Runtime DLL
XPPRT1.DLL : 1.90.0331 Xbase++ Runtime DLL Hotfix Rollup #13
XPPUI1.DLL : 1.90.0331 Xbase++ Runtime DLL, Hotfix Rollup #12 for Xbase++
XppUi2.dll : 1.90.0331 Xbase++ Runtime DLL
-----------------------------------------------------------------------------
oError:args :
-> NIL
oError:canDefault : N
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Unbekannte Variable
oError:filename :
oError:genCode : 22
oError:operation : zPATH
oError:osCode : 0
oError:severity : 2
oError:subCode : 2000
oError:subSystem : BASE
oError:thread : 4
oError:tries : 1
-----------------------------------------------------------------------------
CALLSTACK:
-----------------------------------------------------------------------------
Called from ABTHREAD3(5763)
Called from ABTHREAD2(4069)
-----------------------------------------------------------------------------
Thread 4
-----------------------------------------------------------------------------
{1, 464, 4027, "ABTHREAD1", thread}
{3, 952, NIL, NIL, thread}
{4, 1572, 544, "ERRORLOG", thread}
-----------------------------------------------------------------------------

und hier der Code

Code: Alles auswählen

5763   IF VALTYPE(zPATH) = "U"
5764      zPATH := cDBFPath
5765   ENDIF

jemand eine Idee wie ich das sonst abfangen soll ?

[brandelh]

Hi,

ich frage bei sowas immer:

Code: Alles auswählen

IF zName == NIL

wenn es eine MEMVAR ist ...

Code: Alles auswählen

IF M->zName == NIL

aber eigentlich sollte auch VALTYPE() immer funktionieren

[AUGE_OHR]

Hi,

ich frage bei sowas immer:

Code: Alles auswählen

IF zName == NIL

wenn es eine MEMVAR ist ...

Code: Alles auswählen

IF M->zName == NIL

aber eigentlich sollte auch VALTYPE() immer funktionieren

Das eine PUBLIC "verschwindet" ist ja eine Sache die eigendlich gar nicht
sein kann und dann kann ich die nicht mit VALTYPE() testen ?

Das dürfte doch nie und nimmer einen Fehler geben egal ob definiert,
gelöscht etc ... oder ?

Ich fürchte sogar das bei deinem Code es versagen wird aber das "M->"
könnte ich ja noch mit in die BEGIN/RECOVER mit einbauen um zu sehen
ob es irgendwas bringt.

... natürlich sind haben alle "Demos" nicht gebracht sodas ich das auch
nicht "provozieren" kann ... nix im Debugger was auffällig wäre ...

[Bertram Hansen]

Hallo Jimmy,

wie wäre es mit

Code: Alles auswählen

TYPE("zPATH") = "U"

[AUGE_OHR]

hi,

ich "denke" ich habe eben etwas "mehr" bemerkt, denn leider habe ich das Problem immer noch "ab-und-zu"

Code: Alles auswählen

PRIVATE zPath
// auffüllen
zPath := "\\Server\Blabla\"
// Thread starten
Do_My_Thread()

//
// in einem anderen PRG
//
MEMVAR zPath

PROCEDURE Do_My_Thread()
LOCAL oThread := Thread():new() 
   oThread:start("My_Code") 
...
RETURN

PROCEDURE My_Code()
  //
  // wenn hier ein Fehler auftritt habe ich ein Problem mit zPath
  //  
  USE (zPath+"Kunden.DBF") 
  //  
  //  wenn ich die Memvar "benutzt" habe und er abstürzt "kennt"
  //  er zPath -> Errorlog auf dem Server

in der Errorsys.PRG sieht es nun so aus

Code: Alles auswählen

MEMVAR ZPATH
PROCEDURE ErrorSys()
...
STATIC PROCEDURE ErrorLog( oError, nStackStart )
LOCAL cErrorLog
LOCAL cExtension := "LOG"
...
   IF IsMemvar("ZPATH")
      cErrorLog := ZPATH + EHS_ERRORLOG + "." + cExtension
   ELSE
      cErrorLog :=         EHS_ERRORLOG + "." + cExtension
   ENDIF

   BEGIN SEQUENCE
      SET ALTERNATE TO ( cErrorLog ) ADDITIVE
      SET ALTERNATE ON
   RECOVER
     /*
      * ALTERNATE file could not be opened:
      * try other filename
      */
      cExtension := PADL( ++ i, 3, "0" )

wenn, aus welchem Grund auch immer, zPath nicht vorhanden ist schreibe ich also in das lokale Application Verzeichniss.
... aber warum springt er dann in das RECOVER ???

[brandelh]

nur weil sie DA ist, muss der Typ nicht stimmen
Oder der Pfad ist ungültig.

[UliTs]

Wenn ich es richtig verstanden habe, wird die ErrorLog()-Prozedur bei einem Laufzeitfehler aufgerufen. Ich meine, dies geschieht durch Ausführung eines "Break".
Vielleicht kommt es zur Ausführung des RECOVER-Codes, weil innerhalb einer Break-Anweisung erneut ein Begin Sequence benutzt wird.

Uli

[Tom]

MEMVAR erzeugt standardmäßig PRIVATES, wenn ich nicht irre (ich nutze die Anweisung nicht). PRIVATES sind funktions- und threadlokal, und nur in der Funktion selbst und in von ihr aufgerufenen Funktionen sichtbar.