Zugg Software :: View topic - [2.22] Should the wait commands resume after timeout?

Posted: Sun Apr 20, 2008 9:53 pm

So I was reading the manual to check my facts for this post, and I noticed that when the timeout is reached, the script is aborted. This seemed wrong to me - I seemed to remember that the wait commands resumed their thread on timeout. Whether that was the case or not, I think it should be changed (back) so that the timeout commands are run and then the thread is resumed.

The reason I suggest this is because it's very difficult to produce this behaviour with the current setup. You'd have to store all the code that's after the wait in a function or alias and then call that both after the wait and in the timeout commands, or just paste the whole script into the timeout command verbatim. Very very messy.

If it was changed so that the thread was resumed rather than aborted, it'd be simple to produce the current behaviour - you just stick #abort 1 in the timeout command and go and have a cup of tea. Having it this way allows you to do lots of other things though - store a value in a variable that triggers a slightly different script to be run or a slightly different string to be displayed, continue running the script normally after the timeout, whatever. Much better.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

#WAITFOR was expanded to have additional options. I think we all forgot to document it.
#WAITFOR pattern [timeout] [commands on pattern match] [commands on timeout]
#WAITFOR with only pattern waits indefinitely for the pattern to match then moves on.
#WAITFOR with pattern and timeout moves on when the pattern matches, and aborts the script when a timeout occurs
The full syntax is self expalnatory, but I never tested if captures become available to the "pattern matched" command set.

Looking through the cmd.db #WAITSIGNAL received the same additions as #WAITFOR. Also if you are going to update the help you should use #EXIT in the example rather then #ABORT 1, since I think that is the abortion level they use on a timeout.

Posted: Sun Apr 20, 2008 11:27 pm

No, it's documented - that's how I found out about it. My point is that the thread shouldn't be aborted when the timeout occurs, it should continue. My argument was that it's easy to write a script to make it abort and hard to write a script to make it continue, so make it continue.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I was sorely mistaken it did get documented, and now that I am actually following your thinking instead of trying to do other programming. I also see the point that when a timeout set of commands is provided the remaineder of the thread should be continued. I would even go so far as saying that if any of the optional command portions are present then the thread shouldn't be aborted. Which I am guessing is what you were thinking.

Looking back on it I am rather sure it always did an abort. I remember being a little irritated about how it worked. Zugg added the true and false command portions and I never got around to playing with it to whine some more.

I think this makes the final request for both #WAITFOR and #WAITSIGNAL

Posted: Mon Apr 21, 2008 1:11 am

That's not quite what I meant - the thread should never be cancelled just by timing out, even (perhaps especially) if you don't specify a timeout command. If you want it to cancel, you can say so very easily with #abort. If you don't want it to, you just want it to wait for a pattern or x seconds until the thread resumes, you can just leave it off.

So:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, how would you know it timed out when using the second syntax (#waitxxx whatever timeout)? #WAITFOR could be tested by examining %line, but there is no similar way to test #WAITSIGNAL. I would suggest that syntax really does need some form of cancelling. Perhaps the current #ABORT like behavior is too strong and doing #EXIT would be better. This would change the abort point to cover the current code block while still allowing higher level code to interpret the results correctly. An example of this idea would be

Posted: Mon Apr 21, 2008 3:02 am

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I'll throw my $0.02 in as well....the #WAITxxx commands should NOT abort, exit, or anything else by default.

My reasoning is simple, and has already been explained by Fang.

If a coder wants to exit or abort in the event of a timeout, it is very easy to make that happen using the timeout commands (e.g. #WAITSIGNAL someSig 5000 {} {#EXIT}).
However, if you do NOT want to exit or abort, but the command does it automatically, then you're forced into some really weird coding contortions to get your desired behavior (e.g. use WAITSIGNAL with no timeout, but have an alarm to set a 'timeout' variable and throw the signal anyway).

The only good reason that I can see for having #WAITxxx commands do #EXIT for you is backward compatibility....if they've done one up until now, then we'd break existing code by changing it. Even in that case, however, I'd still advocate for the change, because I think it's a good one.

At the very least, I'd like to see the #EXIT suppressed if the timeout commands are supplied by the coder (even empty, so that '#WAITSIGNAL mySignal 5000 {} {}' would NOT automatically exit) - at least that would allow the other behavior with only minimal contortions.

Wizard Joined: 22 Mar 2007 Posts: 2320

Fang's argument makes sense to me. I wonder how much code this would break? I fortunately haven't used these commands much, though I can see some situations where Fang's version could be useful to me. What I don't know is how much code other people have that would need to be revised.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I've been having some problems with threads in general of late, but haven't had time to narrow anything down.

The only one that I could get to work partly the way I needed it to was #WAITSIGNAL.

I would be ECSTATIC if the timeout commands actually did what I put in the second set of curly braces when the timeout occurred
as apposed to silently eating them and never telling me what the ---- happened to the code I told it to execute. Confused

Posted: Wed Apr 23, 2008 8:25 pm

If I am understanding this discussion, then I think I disagree. The #WAITFOR is a good example. Here is how it was intended to be used in simple scripts. For example, an auto-login script:

Posted: Wed Apr 23, 2008 8:51 pm

I see where you're going with this, in that case - it was just a problem with the documentation, specifically where it says "If the timeout expires, the rest of the thread's script is aborted" because that obviously isn't true in your second example (which works). I had a look at the file in an attempt to fix it, but it's really hard to get the wording right. Perhaps someone else has an idea.

Posted: Wed Apr 23, 2008 9:19 pm

Yeah, it's tricky wording. The script isn't aborted when you use the *full* syntax. Otherwise it is. Basically, unless you tell CMUD what to do when the WAIT times out (using the extended syntax), then the default "action" is to abort the script.

In other words, the simple syntax: