Reference Manual

  • 15.0
  • 07/23/2021
  • Public Content
Contents

Using Blocking Procedures

Procedures that block execution of the program until a given event occurs, such as
READ
or
WAITONMOUSEEVENT
, both of which wait for user input, are called
blocking procedures
. QuickWin child processes can contain multiple callback routines; for example, a different routine to be called for each menu selection and each kind of mouse-click (left button, right button, double-click, and so on).
Problems can arise when a process and its callback routine, or two callback routines within the same process, both contain blocking procedures. This is because each QuickWin child process supports a primary and secondary thread.
As a result of selecting a menu item, a menu procedure may call a blocking procedure, while the main thread of the process has also called a blocking procedure. For example, say you have created a file menu, which contains an option to LOAD a file. Selecting the LOAD menu option calls a blocking function that prompts for a filename and waits for the user to enter the name. However, a blocking call such as
WAITONMOUSEEVENT
can be pending in the main process thread when the user selects the LOAD menu option, so two blocking functions are initiated.
When QuickWin has two blocking calls pending, it displays a message in the status bar that corresponds to the blocking call first encountered. If there are further callbacks with other blocking procedures in the two threads, the status bar may not correspond to the actual input pending, execution can appear to be taking place in one thread when it is really blocked in another, and the application can be confusing and misleading to the user.
To avoid this confusion, you should try not to use blocking procedures in your callback routines. QuickWin will not accept more than one
READ
or
INCHARQQ
request through user callbacks from the same child window at one time. If one
READ
or
INCHARQQ
request is pending, subsequent
READ
or
INCHARQQ
requests will be ignored and -1 will be returned to the caller.
If you have a child window that, in some user scenario, might call multiple callback routines containing
READ
or
INCHARQQ
requests, you need to check the return value to make sure the request has been successful, and if not, take appropriate action, for example, request again.
This protective QuickWin behavior does not guard against multiple blocking calls through mouse selection of menu input options. As a general rule, using blocking procedures in callback routines is not advised, since the results can lead to program flow that is unexpected and difficult to interpret.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.