| |
| |
|
p.specht
 | Frage: Gibt es da nicht Speicherlecks, wenn mit dem Schließen-Kreuz abgebrochen wird statt mit ESC-Taste?
{$cleq}
cls
var n&=0
Print " Theads der Reihe nach beenden mit ESC-Taste!"
var thread&=thread.start(procaddr(meinThread),0,"")
var thread2&=thread.start(procaddr(meinZweiterThread),0,"")
repeat
locate 10,10:print n&:inc n&;
waitinput 5
until %key=27
print "\n Habe Hauptschleife verlassen."
waitinput
thread.stop(thread&)
while thread.is(thread&)
endwhile
thread.close(thread&)
print " Habe Thread Nr. 1 beendet."
waitinput
thread.stop(thread2&)
while thread.is(thread2&)
endwhile
thread.close(thread2&)
print " Habe Thread Nr. 2 beendet."
print " Isch 'abe feddisch..."
waitinput 3000
end
nproc meinThread :parameters thread&,dataLong&,dataString$
whilenot thread.message(thread&)==wm_close
settext(%hWnd,"Mein FensterTitel - ["+time$(0)+"."+substr$(time$(1),1,".")+"]")
sleep(1000)
endwhile
return 0
endproc
nproc meinZweiterThread :parameters thread&,dataLong&,dataString$
whilenot thread.message(thread&)==wm_close
settext(%hWnd,"MEIN FENSTERTI - ("+time$(0)+"."+substr$(time$(1),1,".")+")")
sleep(900)
endwhile
return 0
endproc
|
|
| |
| XProfan 11Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'... | 13.03.2014 ▲ |
|
| |
|
|
Nico
Madysa | Hallo Peter,
ich habe mir die Freiheit genommen, deinen Code aus Lesbarkeitsgründen in [Code]-Blöcke zu setzen. Dabei habe ich auch ein paar Doppelpunkte aus deinem Quelltext gegen Zeilenumbrüche getauscht, weil sie den seiteninternen Einrückungsparser durcheinander gebracht haben.
Was deine Frage angeht, so habe ich ernsthafte Zweifel, dass da ein Speicherleck existiert. Wenn du den Schließen-Knopf drückst, wird das XProfan-Fenster mit DestroyWindow zerstört und beim Ende des Prozesses sollten auch alle Threads des Prozesses zum Erliegen kommen.
Das sind aber alles nur Vermutungen. Wenn du es genau wissen willst, kannst du ja in einer Schleife das Programm ein paar tausend Mal aufrufen und ihm dann ein WM_CLOSE zukommen lassen, bzw. DestroyWindow auf es anwenden.
Wenn sich das nicht im RAM-Verlauf deines Taskmanagers bemerkbar macht, ist die Sache wahrscheinlich sicher. |
|
| |
| |
| |
|
|
p.specht
| Danke für die rasche Antwort, Nico! Bin am testen...
Die Frage bezog sich auch auf diese Anmerkung in der xpse-Funktionshilfe, wonach die Funktion tread.is() fälschlicherweise stets Null liefert - sonst könnte das Hauptprogramm merken und abwarten, wenn noch Threads werken. Kennt da jemand einen work-around?
Gruss
P.S.: Mit 'Mutex' zur Synchronisation muss ich mich auch erst beschäftigen. Einen Vorteil gegenüber Polling sehe ich derzeit eher nicht. Den gibt es scheinbar nur bei Problemarten, die mir bislang noch nicht untergekommen sind. |
|
| |
| Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'... | 17.03.2014 ▲ |
|
| |
|
|
Nico
Madysa | Wenn du keine hohen Geschwindigkeiten brauchst, wäre ein Workaround, XProfan-Multiprozessing zu verwenden. Das ist langsamer, funktioniert aber wenigstens.
Nächste Alternative wäre, mit PExec einen neuen Prozess zu starten, in dem aber wiederum eine NProc aufzurufen. Das ist hässlich, aber das sind Workarounds ja meistens.  |
|
| |
| |
| |
|
|
 | p.specht (13.03.14)
Frage: Gibt es da nicht Speicherlecks, wenn mit dem Schließen-Kreuz abgebrochen wird statt mit ESC-Taste?
Windows säubert (zumindest ab ich glaube) Version XP sowieso bei Prozessende.
Das Programm hätte aber Race-Condition-Probleme wenn der Thread läuft und mit hWnd redet ohne dass es hWnd gibt. Müsstest der guten Ordnung halber also vor Zerstörung des hWnd die Threads ordentlich beenden. Somit wird WindowStyle 512 wohl unumgänglich. |
|
| |
| |
| |
|
(554)
Deutsch
English
Français
Español
Italia