fixed the utexas msg queue and 'radio troubles':)

[statespacedev]

raw data dump here - fwiw fyi - have python agent working pretty good -
normal work flow is six of em telnet in and start 'playing' - random moving around and sending messages over the radio
this is fine with this 'bypass' in place - 1333224
the agents and any additional manual telnet sessions can 'play' indefinitely - interacting with various mayhem from the romulan

k, big pic - the 'agent ships' run out of energy and get destroyed and resurrected after twenty thirty minutes - fine!
but want to build in a 'back brain docking instinct' first, so they at least have some kinda 'survival instinact' hahaha:)

will try to focus on that this weekend - grow some brain stem in the agents - meanwhile, meditate on what's going on in warmac makmsg... any brainstorms merlyn?:)

ciaociao!

[drforbin]

What's wrong makmsg? Also try this.

In develp at prompt

*password *mink
set endflg

[statespacedev]

well, am not really sure what's happening in makmsg - here's the known facts
with 1, 2, 3 ships playing there's no problem game can go on for 12 hours easily
with the 'early return bypass' in place, same is true for 5, 6, 7 ships - but then tell is 'turned off' of course

say there there are 5 ships - game will go along fine for 10, 15, 20 minutes - then one ship will crash first and take a few others with it - most with messages like
**** Lockup on queue Q by job 526
Fatal ENQ. error code 5
**** Lockup on queue F by job 514
Fatal ENQ. error code 5?
?IO to unassigned channel at user PC 455426
usually a few ships are left 'playing normally' - but the overall system is spinning out of control - 100% cpu usage - need to reboot tops-10

[statespacedev]

here can see score board after nine hours of six 'random mover' agents playing:)

[drforbin]

All the tell issues should be fixed in latest devep

[statespacedev]

good to know, thanks merlyn - have studied what you did there, and will study that even more - your work there has excellent clues, have been using it regularaly!:)

[drforbin]

*** Lockup on queue Q by job 526
Fatal ENQ. error code 5
**** Lockup on queue F by job 514
Fatal ENQ. error code 5?
?IO to unassigned channel at user PC 455426

Firstly, what version are you running?

decwar uses an ENQ facility (please refer to the tops10 monitor calls manuals) basically it acts a semaphore in UNIX.
It's used in decwar to only allow access to shared data structures. So for example a job will request access to the shared memory segment and until it's released all other jobs which request the segment will be put to sleep. It's purpose is to prevent run conditions. I think you are overflowing the ENQ queue. Again the ENQ facility was really messed up in CIS code.
I fixed it in later versions! This may be the problem.

[statespacedev]

good grief - just learned a lot by doing a broader 'sync' to development branch -
merlyn i didn't even have enqlck.mac so didn't have that uuo at all!!!
no wonder it was broke - ok - am studying your work merlyn, this is definitely it, will work on this today!:)

[drforbin]

` subttl LOCK/LOCK./UNLOCK/UNLO.

;;; LOCK -- lock a critical data area (don't let anyone else write
; into it until you're done).
;
; CALL LOCK (key,str)
;
; where key is a high segment variable unique to the data area
; being protected, and str is a string to output (generally the
; name of the routine that called LOCK) when the lock is broken
; (the lock is broken if it has to try too many times to access
; the data -- it is assumed that somebody set the lock and didn't
; clear it for some reason after they were done).
;
`

This is in WARMAC as usual.

[drforbin]

FYI The ENQ code is some of the most complex code in decwar and required alot of changes do to the fact CIS changed all the monitor calls.

Basically if I recall it creates a spin lock and tries to release that locks every so many milliseconds and if it can't release within a period of time it signals an error. I think that how it works if my mind is recalling correctly!

[statespacedev]

yep, understood - more to learn here for me, for sure - will learn from all your changes merlyn, thanks for this!:)

[drforbin]

'lock.0:
caie t2,1 ; if not busy resourse
jrst [caie t2,13 ; then if not out of memory
jrst [outstr [asciz "
Fatal ENQ. error code "]
move t1,t2 ; report the error code
pushj p,debdec
jrst monit ; exit stage left!
]
movei t2,^d1000 ; hibernate a second
hiber t2,
jfcl
jrst lock.5 ; and try once again
]
'

[drforbin]

Let me know when you and/or mr freeman wish to talk...I will then brief you on the ENQ etc.
As I said. You really should stick with devel. CIS changed all the UUos and I had to reverse engineer and then rewrite it to standard tops10.

[statespacedev]

yep will do - understood, didn't really realize till now some crucial stuff may be only in development branch - learning from it now:)

[statespacedev]

wow! with enqlck.mac in action now, tell cmd is obviously working muuuuuuch better -
snappy, interrupting properly on receive end, etc
this was a HUGE jump up - thanks merlyn, this was all thanks to your help!:)
will keep on truckn - lesson learned 'study and use development branch!!!':)

[statespacedev]

[drforbin]

decwar uses some very advanced programming techniques...ELON could learn from tops10

[statespacedev]

decwar code is fascinating stuff...!!! we're workn to preserve something very special here amigo!:)

[drforbin]

You gotta watch run conditions! remember NONE of these accesses are atomic.

[drforbin]

I'm glad you feel that way. Sometimes I feel very much alone in this endeavor

[drforbin]

If I recall correctly the implementation of ENQ is really interesting. I believe it calls the ENQ facility in NON BLOCKING mode and then calls hibernate. it returns, then call ENQ until the lock is released. If it is released it grabs the lock, if not it hibernates again.
It's a real novel implementation because it could have been done in blocking mode, but i think the developers want to be able to test periodically.

[statespacedev]

confirmed that syncing utexas warmac to merlyn's dev branch and bringing in enqlck.mac fixed the prob!:)
six agents are 'playing' just fine now - commit updating utexas is in! 6026e5a

[drforbin]

Noah, I don't understand why you don't just use devel. Just asking.

[statespacedev]

project utexas is completely bout 'going backwards' - trying to remove things to go back as near as possible to the 'original utexas tape' - so the file and folder structure, 18 ships, original help file, etc - having enqlck.mac there is cosmetically questionable actually, may try moving that code inside warmac.mac so that least superficially things looks the same as before:)

[drforbin]

Also devel helps with understanding because I added the cloaking device which require modifying 'adding' alot of data structures which can help you understand how everything fits together.

[statespacedev]

yep, very true - it's fantastic for learning and understanding!

[drforbin]

Noah, don't know if your interested in this or not but I am totally rebuilding my engine in my Exotic sports car.
Heres the link if your interested.

https://www.youtube.com/@AutoFix-k5e

[statespacedev]

will check it out merlyn!:)