Archive of UserLand's first discussion group, started October 5, 1998.
sys.systemTask vs. thread.sleepFor
Author: Doug Baron Posted: 1/12/1999; 10:04:20 AM Topic: sys.systemTask vs. thread.sleepFor Msg #: 2027 Prev/Next: 2026 / 2028
Rooted in history, there's often confusion about the right way to "busy loop" in Frontier. In the old days, there weren't any thread verbs; sys.systemTask was the one call recommended to use inside of a loop constuct to avoid hogging the processor.With the advent of the thread verbs, another, usually better option is available: thread.sleepFor. It takes one parameter, the number of seconds to sleep. If you sleepFor(0), the thread is put to sleep and immediately reawakened, basically sitting out one or two rounds of thread processing.
When should each verb be used? That depends on what the busy loop is waiting for. If it just performed a UI operation, and is waiting for an update or other events to be handled, sys.systemtask is the way to go. This verb explicitly services window activation events, and incoming Apple events on the Macintosh. It yields to other threads one time, avoiding the overhead of a sleep/wake cycle.
OTOH, if the loop is waiting for tcp activity, or for another thread to complete, thread.sleepFor(0) is preferred. This verb gives more time to other threads than sys.systemTask does. Furthermore, if immediate response to the outside event isn't critical, sleeping for one or more seconds will greatly reduce the loop's overhead on the system.
One other note: sys.systemTask is much faster under Windows than it is on the Mac. This is due to the fact that it will always generate at least one call to WaitNextEvent, allowing the OS to swap Frontier out entirely. On Windows, where apps multitask preemptively, the overhead of checking for events is greatly reduced.
Doug
This page was archived on 6/13/2001; 4:47:13 PM.
© Copyright 1998-2001 UserLand Software, Inc.