Multi Threading and Background Processes


1. How do I do background processing?

Create the background task as a separate program and compile it to an EXE file. The background task should be a program not requiring user input, for example it could read in a file specified on its command line and produce a file containing the results. The program that wants to run the background task calls it as follows:

  call Exec(BackgroundTask.exe, "InputFile.txt", EXEC_NOWAIT)

This starts running the background task. The caller should periodically check to see if the background task has finished, for example by checking for the existance of a file it will be creating. When the file exists, the background task has completed and the data is avaible to the caller.

For example, a background task could be written that factorizes a number passed to the program on its command line. A calling program would have a user interface allowing entry of the number to be factorized, and a GO button to run the background task. Multiple numbers could be entered by pressing GO after each one, which would cause the background task to run in parallel with different numbers. As each background task finishes and the factors become available, the caller would display the results. As a further refinement, the caller could obtain the list of running programs and show which background tasks are currently running. This arrangement has the advantage that on a multi processor computer, multiple background tasks run in parallel and do not take up extra time.

2. How do I avoid locking up the user interface during a lengthy operation?

There are several ways of doing this:

  • If the lengthy operation can be separated into a background task, write the background task as a separate program. Then use Exec with the EXEC_NOWAIT option to run the background task, noting that Exec gives you additional options to control the window state of the background task. The background task enables the calling program to continue with other tasks. This maintains a responsive user interface.
  • If the lengthy operation is quite short (for example just a few seconds) then it does not matter if the main program's user interface is temporarily locked up. This is because the Ubercode interface is 'smart' in the sense that when you run a lengthy process, it automatically changes the application cursor to an hourglass and keeps the window appearance updated. This provides user feedback.
  • The lengthy operation may be able to run 'callback' code on a repeated basis, for example a sorting algorithm could run code each time part of the input data has been sorted. If the callback code is able to communicate with the user interface, it can make sure the user interface is responsive. For example it could check if a Cancel button has been pressed, or it could update a progress control. This assumes the process can be structured so as to make regular checks to the interface, and assumes it can be halted while underway.

Ubercode does not include support for separate threads or fibers since it is a mainstream language, and these features are used only by languages that make direct calls to the Windows API. In Ubercode multi threading is replaced by multi tasking through separate processes, and multi tasking is fully supported.