Starting an additional thread is always a 'request' because the resources of the target machine are limited. The word 'request' indicates that Windows may not grant the application another thread, which can happen because there are simply no unallocated processing resources available when the thread request is made. If no additional threads are available from the Windows operating system, the Supervisor queues up the incoming requests until threads are available or the programmer-defined timeout in the Supervisor instance configuration expires.
I can't speak for every other application, but in APL+Win one can:
Start another .exe-type program, which runs in a separate thread, e.g. using the Win32 API CreateProcess method, but once started it is not under the direct control of the APL+Win program which started it. Interaction, if any, between APL+Win an the running .exe must be done with a programmer-defined protocol comprehended by both APL+Win and the .exe, e.g. files. Such an interface is likely to be synchronous with respect to APL+Win.
Create an instance of an ActiveX component and use the object model of that component, i.e. methods, properties and events. APL+Win interacts with the methods and properties in a synchronous manner, i.e. APL+Win must wait for the response from the ActiveX component. The events, if any, in the object model of the ActiveX component provide the asynchronous [independent thread] capability and not the APL+Win calling environment.
Now think of using an APL+Win [client] to start one or more APL+Win ActiveX instances [servers] in an attempt to spread the processing load to increase application system performance. When the client uses the 'Call' method to run an APL+Win function in one of the APL+Win ActiveX servers, the client must now wait for that server-side function to complete execution. While that server-side function is running, the client cannot execute other APL statements, because the Call method is synchronous. While the server-side function is running the client cannot use the Call method to run another server-side function in another APL+Win ActiveX instance.
The APLNext Supervisor extends APL+Win so that it can asynchronously interact with multiple APL+Win-based tasks, effectively providing application-level parallel processing. Using the Supervisor, multiple tasks, .e.g 'Kernel' functions, can be simultaneously running in multiple APL+Win ActiveX instances, while the client, i.e. 'Controlling Application', which started those ActiveX instances can continue executing additional APL+Win statements. No special programming has to be added to the 'Kernel' functions since the Supervisor provides the asynchronous interface to those 'Kernel' functions.
In the latest version of the APLNext Supervisor the asynchronous feedback to the 'Controlling Application' from the 'Kernel' function can occur when that function completes execution, i.e. using the ProcessCompleteCallback Supervisor event and at any stages in the execution of that function, i.e. using the ProcessProgressCallback Supervisor event.