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
