Nochmals ObjMarkDirty

bolle732 · September 24, 2024 at 5:57 PM New

Ich verwende ja in der MSG_GEN_PROCESS_CLOSE_APPLICATION Methode die Function ObjMarkDirty() um die "aktiven" Objekte in de State zu bekommen. Das funktioniert soweit ganz gut, nur Swat meckert und verabschiedet sich mit "Death due to block not locked".

Code

ObjMarkDirty(@LadderView);
ObjMarkDirty(@LadderGameActors);
...

Das sind alles abgeleitet Vis-Klassen und eigentlich alle in der selben Ressource. Wenn ich versuche das zu Locken, stirbt der Patient mit CANNOT_CALL_MEM_LOCK_ON_AN_OBJECT_BLOCK.

Code

MemLock(OptrToHandle(@LadderView));

Irgendwie hänge ich hier. Ohne Swat funktioniert es ansonsten wie gewünscht. Die Objekte behalten Ihren State über einen Neustart.

In den Quellen gibt es auch nur sehr weniges dazu. Meistens ist es auch noch jeweils auskommentiert...

Rainer · September 24, 2024 at 6:18 PM New

Du musst die normalen Objekte nicht extra dirty setzen. Das passiert automatisch, zumindest bei Gen-Objkete. Bei Vis bin ich mir nicht sicher, denke aber auch. Am besten ausprobieren.

Ansonsten: Die Messages, die du den Objekten sendest haben oftmals einen "Objekt-Flags" Parameter. Da kannst du oft auch ein Mark-Dirty Flag übergeben.

bolle732 · September 24, 2024 at 9:13 PM New

Sie sind eben leider nicht automatisch Dirty. Ohne ObjMarkDirty() haben sie nach einem Neustart die Default-Werte. Mit kommen sie dann auch wieder mit den richtigen Werten.

Ich Frage mich nur, warum Swat will, dass ich Locke, aber dann reklamiert, dass Ressourcen mit ui-objekt Attribut nicht gelockt werden dürden.

mgroeber · September 25, 2024 at 3:33 PM New

Quote from bolle732
Das sind alles abgeleitet Vis-Klassen und eigentlich alle in der selben Ressource. Wenn ich versuche das zu Locken, stirbt der Patient mit CANNOT_CALL_MEM_LOCK_ON_AN_OBJECT_BLOCK.
Code
MemLock(OptrToHandle(@LadderView));

Wenn ich mich richtig erinnere, gibt es dafür ObjLockObjBlock().

siehe: https://bluewaysw.github.io/pcgeos/Routines/rroutm_p.html

bolle732 · September 25, 2024 at 5:03 PM New

Ich habe das ausprobiert:

Code

ObjLockObjBlock(OptrToHandle(@LadderView));

Jetzt bekomme ich eine Meldung wegen falschen Thread:

Code

Death due to OBJ_LOCK_OBJ_BLOCK_BY_WRONG_THREAD
finish+21:           MOV     AX, 526 (020eh)
Execution died in patient geos:
finish+21:           MOV     AX, 526 (020eh)
*** No explanation available ***
Interrupt 3: Breakpoint trap
Stopped in FatalError, line 870, "/home/bolle/pcgeos/Library/Kernel/Boot/bootBoot.asm"
       push    bp, si, ds, ax
(ladder:0) 2 => bt
 1: near FatalError(), bootBoot.asm:870
* 2:  far ObjLockObjBlock(), objectClass.asm:3484
 3:  far OBJLOCKOBJBLOCK(), objectClass.asm:3415
 4:  far LADDERPROCESSGEN_PROCESS_CLOSE_APPLICATION(), process.goc:680
 6: call ladder:0{_LadderProcessClass}MSG_GEN_PROCESS_CLOSE_APPLICATION(2201h 4e20h 0024h 0024h) (@1, ^l4dd0h:0024h)
 6: near ObjCallMethodTable(), objectClass.asm:1700
 7: near ObjCallMethodTableSaveBXSI(), objectClass.asm:752
 8:  far SendMessage(), objectClass.asm:197
 9:  far ObjMessage(), geodesEvent.asm:1796
10:  far UI_Ack(), procClass.asm:1880
12: call ladder:0{_LadderProcessClass}MSG_META_ACK(2e60h 4e20h 0024h 001eh) (@2, ^l4dd0h:001eh)
12: near ObjCallMethodTable(), objectClass.asm:1311
13: near ObjCallMethodTableSaveBXSI(), objectClass.asm:752
14:  far SendMessage(), objectClass.asm:197
15:  far ObjMessage(), geodesEvent.asm:1796
16:  far MessageDispatchDefaultCallBack(), geodesEvent.asm:1432
17:  far MessageProcess(callBack = 1585h:14e3h (geos::kcode::MessageDispatchDefaultCallBack)), geodesEvent.asm:1334
18:  far MessageDispatch(), geodesEvent.asm:1134

Display More

Ich bin da ja im Process-Thread und das Objekt ist im Application-Thread...

bolle732 · September 25, 2024 at 5:06 PM New

Wäre hier die Lösung, aus der MSG_GEN_PROCESS_CLOSE_APPLICATION heraus eine Methode der Application-Klasse aufzurufen?

Rainer · September 25, 2024 at 10:39 PM New

Ich würde jetzt versuchen, für deine Objekte eine Methode zu defineren (MSG__MY_OBJ_MARK_DIRTY), nichts weiter tut, als "sich selbst" Dirty zu machen, mit ObjMarkDirty(oself). Die rufst du dann in CLOSE_APPLICATION vor @callsuper(). Sobald das Objekt eine Methode ausführt, ist es immer gelockt.

Leider habe ich keine "vordefinierte" Message gefunden die das macht. Was ich erstaunlich finde.

Rainer

bolle732 · September 26, 2024 at 7:42 AM New

Hallo Rainer

Das hört sich nach einem pragmatischen Weg an. Besten Dank!

Ja, man merkt schon, dass PC/GEOS schlank gehalten wurde. Das macht es etwas aufwendiger, den richtigsten Weg der Möglichen zu finden

Andreas

jpolzfuss · September 26, 2024 at 7:50 AM New

Das MSG__MY_OBJ_MARK_DIRTY müsstest Du vermutlich mit @call aufrufen, damit es auch garantiert vor @callsuper(); ausgeführt wird, oder?!

bolle732 · September 26, 2024 at 7:54 AM New

Ja, denke auch, dass das hier wichtig wäre.

bolle732 · September 26, 2024 at 10:46 PM New

Noch ein Zwischenstand. Es gibt eine Message, nur war mir das nicht so offensichtlich:

Code

@call LadderView::MSG_META_SET_FLAGS(OptrToChunk(@LadderView), OCF_DIRTY, 0);
@call LadderGameActors::MSG_META_SET_FLAGS(OptrToChunk(@LadderGameActors), OCF_DIRTY, 0);
...

Ich werde es aber noch über den Weg meiner View versuchen, diese sich selbst und ihre Kinder mit einer Message auf Dirty zu setzen.

Rainer · September 27, 2024 at 7:39 AM New

Cool. Das war mir auch nicht offensichtlich. Danke.

bolle732 · September 27, 2024 at 11:21 AM New

Hier noch meine aktuelle Implementierung...

APPLICATION CLOSE:

Code

optr o;
// Mark the visible objects dirty
o = @call LadderView::MSG_GEN_VIEW_GET_CONTENT();
@call o::MSG_SCN_MARK_DIRTY();

MARK DIRTY:

Code

@method LadderScreenClass, MSG_SCN_MARK_DIRTY
{
  word i, n;
  optr o;
  ObjMarkDirty(oself);
  n = @call oself::MSG_VIS_COUNT_CHILDREN();
  for (i = 0; i < n; i++)
  {
    o = @call oself::MSG_VIS_FIND_CHILD_AT_POSITION(i);
    ObjMarkDirty(o);
  }
}

Display More

Muss dies dann noch mit EC ALL testen...

Rainer · September 27, 2024 at 10:29 PM New

Die Schleife könnte ein Problem haben,. wenn du KEINE Children hast. Ansonsten sollte es so gehen.
Irgendwo gibt es sowas wie @send-to-Vis-Children. ich glaube das läuft über @record Da müsste ich jetzt aber graben ...

bolle732 · September 27, 2024 at 11:01 PM New

Hallo Rainer

Alle LadderScreen Objekte haben Kinder (composites). Wenn keine vorhanden wären, würde ich eine 0 für n erwarten. In dem Fall sollte die for-Schleife nicht erfüllt sein (i und n sind 0, i < n nicht wahr) ... oder sehe ich das falsch?

Das mit dem @visChildren geht leider nur mit @send. Hier aber sollte ich sicherstellen, dass die Methoden sicher aufgerufen wurden und Objekte sich als Dirty markiert haben.

Herzlichen Dank und ich bin immer offen für Hinweise

Andreas

jpolzfuss · September 27, 2024 at 11:44 PM New

Kleiner Tipp: Nach Möglichkeit „++i“ statt „i++“ nutzen.

++i inkrementiert i um 1 (äquivalent zum Assembler-Befehl „INC“).

i++ ist nur eine Kurzschreibweise für „i = i + 1“. Es wird also erst das Ergebnis von „i + 1“ berechnet, dann wird das Ergebnis der Variable i zugewiesen. (Jedenfalls, wenn der Compiler hier keine Optimierungen macht.)

Das Ergebnis der beiden Varianten ist zwar identisch, i++ benötigt allerdings (ohne Optimierung) mehr Rechenschritte und ist dadurch langsamer.

Rainer · September 28, 2024 at 10:47 AM New

jpolzfuss das mit der Optimierung war mir auch nicht bewusst. ... laut C-Doku führt er bei ++i das Erhöhen vor der Verwendung von i aus, bei i++ (irgendwann) nach der Verwendung von i. Very confusing. In der Schleife sollte da aber egal sein.

bolle732 du scheinst recht zu haben, laut Internet ist for() in C abweisend. Ich hab immer geglaubt sie sei nicht abweisend. Trotzdem - oder deswegen - und auch zur Klarheit würde ich persönlich hier versuchen while zu verwenden: while(numChildren>0) { .... numChildren--; }

Solange alle deine Children sicher in der gleichen Ressource wie das Parent liegen, ist die Lösung sehr schön. Tun sie es nicht, hast du wieder das ObjMarkDirty()-Problem vom Anfang.

Rainer

bolle732 · September 29, 2024 at 4:21 PM New

Quote from Rainer

Solange alle deine Children sicher in der gleichen Ressource wie das Parent liegen, ist die Lösung sehr schön. Tun sie es nicht, hast du wieder das ObjMarkDirty()-Problem vom Anfang.

Ja, das tun sie zum Glück und sollte auch nicht anders werden

Das mit den Schleifen und dem Erhöhen vor- / nachher ist interessant. Mir ist die For persönlich geläufiger. Bei While fange ich immer an weiterzudenken, ob ich da nicht irgendeine eine Endlos-Schleife baue

mgroeber · October 1, 2024 at 10:45 PM New

Noch ein Gedanke zu "mark dirty": das typische Muster, das ich immer für so ein Flag im Kopf habe, ist dass man ein Objekt "dirty" setzt, sobald man irgendwelche Änderungen daran macht, die man speichern will. Es ist dann eher so was wie der Zustand "nicht gespeichert" bei einem Dokument.

Aber wenn sich der Zustand sowieso immer ändert, reicht es auch, einmal am Ende alles pauschal "dirty" zu setzen.