Hallo,DarkSoul hat geschrieben:Hab mal gaanz kurz in das Repo reingeschaut bzw. an den üblich verdächtigen Stellen für sowas debuggt. Wenn ich das richtig sehe, kommt folgende Situation gelegentlich vor:
Der Thread, der die Tiles lädt, wird sein PostEvent (z. 1196) nicht los und kommt daher innerhalb der per Mutex gesperrten "Strecke" zum Stillstand, weil der Mainthread in Zeile 1206 an der noch gesperrten Mutex auf Einlass wartet und somit nicht für das Event aus dem Thread empfangsbereit ist, so dass der Lade-Thread die Mutex nicht freigibt, damit der Mainthread weiter laufen kann, um das Event aus dem PostEvent in Empfang nehmen zu können, damit der Thread ebenfalls weiterlaufen (bzw. in diesem Fall zuende laufen) kann.
Somit blockieren sich beide Threads gegenseitig und das Programm kommt zum Stillstand, da einer der Threads der Mainthread ist.
Wenn man den Code bei z. 1196 herum etwas abändert, ist das Problem weg und dann läuft's sogar etwas besser.
Habe mal ein bisschen Pfuschi-Pfusch das PostEvent aus dem Mutex-Abschnitt herausgezogen, so dass diese Verklemmung nicht mehr passieren kann:
Code: Alles auswählen
LockMutex(PBMap\MemoryCacheAccessMutex) Protected *a = PBMap\Window Protected *b = PBmap\Gadget UnlockMutex(PBMap\MemoryCacheAccessMutex) PostEvent(#PB_Event_Gadget, *a, *b, #PB_MAP_TILE_CLEANUP, *Tile) ; To free memory outside the thread
ich habe keinen fremden Code oder Libraries benutzt sondern alles mit eigenem PB-Code entwickelt. Ehrlich gesagt wusste ich nicht mal von PBMap.
Unter Win64 läuft Topotracker bei mir in der Entwicklungsumgebung und als Anwendung stabil.
Ich benutze auch keinen Thread sondern regele das fortlaufende Zeichnen der Map über einen Eventtimer und einem Flag in der Event-Schleife.
Gruß
Erich