NOYIELD

NOYIELD tells FMSLogo not to interrupt running Logo instructions to process windows messages, such as keyboard input, mouse clicks, or notifications to repaint the screen. When FMSLogo is in NOYIELD mode, it is unresponsive while running Logo instructions and ignores important user interactions such as pressing on the Halt Button. FMSLogo may appear to lock up until the Logo code finishes or it runs YIELD.

The default mode is to yield, but KEYBOARDON, MOUSEON, and some SETTIMER event callbacks are run in NOYIELD mode.

The notion of not yielding was historically more significant when Windows was a cooperative multi-tasking operating system and applications had complete control of the CPU until they opted to yield to other applications. Once an application had yielded, it would have to wait until all other applications had yielded before it could run again, and there was no way of knowing how long that would take. As such, to guarantee good performance, applications would not yield until they had run out of work to do. Nowadays, Windows gives all applications a fair amount of CPU time, so NOYIELD only prevents FMSLogo from interrupting itself. These interruptions are generally desireable, which makes it difficult to use NOYIELD well. Nonetheless, NOYIELD is available because FMSLogo runs faster in some cases if it cannot be interrupted.

You can achieve the proper balance between performance and responsiveness for your programs by understanding the examples given below. Let's say that you have nested loops in your program and that most of the real work is done in the inner loop.

Case 1: User in control for 10,000 operations, lower performance:

YIELD
REPEAT 100 [
  REPEAT 100 [
    ; (work to be done)
  ]
]

Case 2: User out of control for 10,000 operations, good performance:

NOYIELD
REPEAT 100 [
  REPEAT 100 [
    ; (work to be done)
  ]
]

Case 3: User out of control for 100 operations, still good performance:

REPEAT 100 [
  NOYIELD
  REPEAT 100 [
    ; (work to be done)
  ]
  YIELD
]