pause
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | pause [2006/08/29 16:08] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | # $EPIC: pause.txt,v 1.2 2006/08/19 03:58:07 sthalik Exp $ | ||
+ | ======Synopsis: | ||
+ | __pause__ < | ||
+ | |||
+ | ======Description: | ||
+ | __PAUSE__ performs a nonblocking sleep for < | ||
+ | nonblocking sleep, the client performs all actions as normal, except that | ||
+ | __PAUSE__ will not return until < | ||
+ | things might have occurred during the nonblocking sleep, it not guaranteed | ||
+ | that everything is as it was when the __PAUSE__ started. | ||
+ | closed, the input line may have changed, dccs may have finished, etc. | ||
+ | __PAUSE__ does not guarantee to return promptly -- in fact, it might not | ||
+ | return at all (if the user does [[QUIT]] during the interval). | ||
+ | user performs some blocking or recursive command during the interval, | ||
+ | __PAUSE__ will not return until all blocking/ | ||
+ | This could be substantially longer than < | ||
+ | |||
+ | You don't want to use __PAUSE__ to stall for a certain amount of time | ||
+ | before running a command if you need any sort of precision, because | ||
+ | __PAUSE__ offers no guarantees when it will return. | ||
+ | command after a precise interval, use the [[TIMER]] command. | ||
+ | use __PAUSE__ as a substitute for [[WAIT]] because server requests offer | ||
+ | absolutely no guarantees how long they might take. I have seen [[WHOIS]] | ||
+ | requests take well in excess of 900 seconds to come back. | ||
+ | |||
+ | < | ||
+ | < | ||
+ | |||
+ | ======History: | ||
+ | The __PAUSE__ command first appeared in EPIC3.003. | ||
+ | Support for sub-second resolution first appeared in EPIC4-1.1.2. | ||
pause.txt · Last modified: 2006/08/29 16:08 by 127.0.0.1