 |
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
 Posted: Mon Dec 13, 2010 5:57 pm
[3.32] Alarm created for the wrong window when executed in another thread.
|
I have an alias that does a #WAIT, and then later creates an alarm with #ALARM and specifies the class for the alarm to go into. Normally this works fine, however I believe occassionaly when the main CMud thread is doing something for the other window, it will create the alarm for the other window. I put a #SA in the alarm and the #SA normally comes out of the main window, but every few hundred times it comes out of the other window instead and the alarm execution fails. Is there a way to prevent this from happening? Perhaps I should abandon using #WAITs and convert back to all #ALARMs.
|
|
|
|
|
Rahab
Wizard
Joined: 22 Mar 2007
Posts: 2320
|
Posted: Mon Dec 13, 2010 6:18 pm
|
Show us the alias.
What is the main thread doing for the other window? Show us that, too, if you can. It's hard to answer this without knowing what you are actually doing. |
|
|
|
|
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
Posted: Mon Dec 13, 2010 9:44 pm
|
Hey Rahab,
The other window is just a #CAP. I got a hp bar trigger that does the following:
| Code: |
#GAG
#CAP hp
#NOMAP
|
Then I have a prompt mapping trig that does the following:
| Code: |
#SA Before OK, nextdir %nextdir, destroom %destroom, inwalk %inwalk, walkconfirm %walkconfirm, walkroom %walkroom, roomnum %roomnum
#OK
#WAIT 10
#SA After OK, nextdir %nextdir, destroom %destroom, inwalk %inwalk, walkconfirm %walkconfirm, walkroom %walkroom, roomnum %roomnum
#ALARM onwalkendtrig +0.1 {
#SA Onwalkendtrig
... Other mapper stuff that fails if alarm is executed for the other window.
} MapClass
|
So most of the time both the #SA for the After Ok and the Onwalkendtrig execute in the same main window, but every 100 or 1000 times the Onwalkendtrig is displayed in the HP window and the code fails. There is no MapClass in the HP window settings either.
Thanks! |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Dec 13, 2010 10:28 pm
|
The context of a script after a #WAIT is not defined. The workaround for this is to usually put a #MODULE command after the #WAIT command to reset the current module back to the proper window. For example:
| Code: |
#WAIT 10
#MODULE MainWindowName
#ALARM ... |
In general after a #WAIT the script context is not necessarily the same as it was before the #WAIT, since any other script could have executed and you might be resuming from #WAIT while CMUD is in the middle of running another thread. That's what Windows does with threads. As soon as you have multiple threads, any thread can start running in the middle of any other thread execution. So CMUD can't just change the context when it resumes your #WAIT script because some other script might be in the middle of running.
This is why you should only generally do "simple" stuff after a #WAIT, like send a command to the MUD. Any variable access needs to be protected with #SECTION to avoid two scripts from accessing the same variable at the same time.
Why do you need to create the #alarm after the #wait?? Can't you create the #alarm before doing the #wait? After all, the alarm isn't going to run until 100ms have passed, so it will run after the "#WAIT 10" even if you define it first. |
|
|
|
|
robert
Wanderer
Joined: 25 Feb 2004
Posts: 98
|
Posted: Mon Dec 13, 2010 11:00 pm
|
Thanks Zugg. That is kinda what I figured was happening. Do you not think that the newly spawned thread should not have the same context saved as part of that thread though?
I should be able to put the #ALARM before the #WAIT as stated. However I am thinking I should just got back to all alarms as I believe that will remove the multiple threads? I work in multithreaded software for a living, but I don't know I want to have to deal with it in my mudding code as I already have ran into race conditions with the multiple threads and the mapper. There isn't an actual performance boost as it will only use 1 CPU anyways so it doesn't seem to have too much of an advantage. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
