 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
 Posted: Wed Nov 14, 2007 7:42 pm
[2.11] #SUSPEND thread does not suspend #WAITFOR
|
I checked all the other forms of wait and #SUSPEND will properly disable them, but one holding on a #WAITFOR does not suspend.
1. Launch CMud
2. Close Sessions window (ESC)
3. Enter at the command line
| Code: |
| #THREAD a {#WAITFOR text;#SHOW done};#SUSPEND a;#THREAD;#SHOW text |
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Nov 14, 2007 8:54 pm
|
#WAITFOR has already suspended the thread. So what do you want #SUSPEND to do?
|
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Wed Nov 14, 2007 9:19 pm
|
I guess I will give the full example first
| Code: |
| #THREAD a {#WAITFOR text;#SHOW done a};#SUSPEND a;#THREAD b {#WAITSIGNAL text;#SHOW done b};#SUSPEND b;#THREAD c {#WAITTHREAD a;#SHOW done c};#SUSPEND c;#THREAD d {#WAIT 5000;#SHOW done d};#SUSPEND d;#THREAD |
Notice how all of them display a status of "stopped" except for the one with the #WAITFOR. While they are in this state they do not notice the things they were waiting on. Once a #RESUME is done for them they are back to paying attention to the time, signal, or state of another thread. I was just expecting that using #SUSPEND on the thread waiting for a text match would no longer be checked for matching text in the same way as the other WAITs. I am not sure I would ever use threads in such a fashion, but still it is good to have them working consistently. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
JQuilici
Adept
Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX
|
Posted: Wed Nov 14, 2007 10:13 pm
|
Following your instructions with 2.11:
| Code: |
Threads:
# ID Window Name Status Script
-------------------------------------------------------------------------------------------------
1 [u] untitled running #THREAD a {#WAITFOR text;#SHOW done a...
2 a untitled stopped Compiled #THREAD command argument
3 b untitled stopped Compiled #THREAD command argument
4 c untitled stopped Compiled #THREAD command argument
5 d untitled stopped Compiled #THREAD command argument
|
Looks right to me. The only thing not stopped is thread 1 (the command line). In particular, thread 2 (named 'a') IS stopped, just like everything else. At this point, typing '#fire text' will produce no response.
Follow up with:
| Code: |
| #resume a;#resume b;#resume c;#resume d;#thread |
and get
| Code: |
Threads:
# ID Window Name Status Script
-------------------------------------------------------------------------------------------------
1 [u] untitled running #resume a;#resume b;#resume c;#resume...
2 a untitled wait for pattern: text
3 b untitled wait for: Signal: text
4 c untitled wait for: Thread: a
5 d untitled wait 4990 ms Compiled #THREAD command argument
|
About 5 secs later, 'done d' will appear. If you '#fire text', thread a and c will complete as well. |
|
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you! |
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Wed Nov 14, 2007 10:39 pm
|
Thanks jquilici, I always appreciate having a second set of eyes look at these things. It must have been a problem with some of the other thread tests I was doing. I should have followed my own rules for making sure it actually does it from a fresh launch before posting. Now I will have to go try to recreate the conditions that caused it to not work again.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Thu Nov 15, 2007 3:48 pm
|
I finally found a set of circumstances that generates this bug consistently. It turns out the bugs are a display issue in #THREAD, and a problem with #SUSPEND.
1. Launch CMud
2. Close Sessions window (ESC)
3. Enter at the command line
| Code: |
| #THREAD a {#WHILE (1) {#WAITFOR text;#SUSPEND b;#SHOW fired a}};#THREAD b {#WHILE (1) {#WAITFOR text;#SHOW fired b}};#TRIGGER {text} {#SHOW fired trigger} |
4. Enter at the command line
5. Enter at the command line
6. Enter at the command line
7. Repeat steps 4 and 5
You will see that the 'b' thread doesn't appear to be suspended in the initial display of #THREAD, but unless it happens to go first when you do step 4 it never passes the #WAITFOR. After step 6 you will see that the 'a' thread never gets suspended.
Having repeated this test enough time I can say without a doubt that there is no way to use threads as a complete replacement of triggers. I will still likely think of some spots where they are useful as a replacement. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Nov 15, 2007 5:45 pm
|
I'll test your procedure later today.
But I've also been considering something else for #WAITFOR. I was using it in some of my own scripts over the weekend, and I found that what I really wanted was to execute some different code when the #WAITFOR timed out. So now I'm considering this extended syntax for #WAITFOR:
#WAITFOR {pattern} timeout {commands if pattern matched} {commands if timeout}
You'd still be able to use the existing short syntax. But when using this expanded syntax, the you have exact control over which commands are executed when the pattern is received, and which commands are executed when it times out. And neither of these would cause the script to be aborted.
It's actually very easy to implement this in CMUD, and I'd consider adding the extended syntax to the other Wait commands that have a timeout associated with them (#waitsignal and #waitthread).
What I was actually doing was a simple "recall" alias. On Aardwolf, a recall might be blocked depending upon what area you are in. So I wanted to make sure that the mapper was only updated if the recall was successful. So I did something like this:
| Code: |
#ALIAS recall {
~recall
#WAITFOR "Name of the Recall room goes here" 2000
#RECALL
} |
So, if the name of the recall room isn't seen within 2 seconds of sending the recall command to the MUD, then it aborts. Otherwise it uses #recall to set the mapper position properly.
The above script doesn't need the new extended syntax, but it's a good practical example of a case where the new #WAITFOR command is *very* easy and useful. Doing this with triggers would require a more complex script that enables and disables the trigger, and has an alarm to disable it after a timeout. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Thu Nov 15, 2007 6:10 pm
|
Something like the additional syntax you are poroposing was pretty much exactly why I was testing with this. I had the thought that I would have a thread sitting at the waitfor. When it timed out or other text was received that invalidated that wait, I wouldn't want it to be trying to match that anymore. I also didn't want to destroy the thread and incurr the overhead of creating another thread and compiling the code. That additional syntax would definitely make things easier.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
|
|
|
