I will certainly not dispute that threading/parallel usage is one of the areas where vfp age shows ;-)
But - as I had already forced/faked coroutines under DOS via ModulaII capabilitiesin the 80ies - similar stuff was given to me under FPW and vfp.

>>>PS: Maybe it wouldn't give an idea that way, if the code explicitly not coded to use async routines (then comes the question, is there a support for it in an easy way as in other languages).

If you need something executing interrupt-like when asynch task is finished, this works great via old OLE linking and embedding. Always needs different process, but hey, CPython nearly lways uses other process unless fed special libs.

Nowhere near Javascript evolution in that area, but HTTP as basis needs asynch more than most vfp apps ;-)
PITA for the first set up, but after that adequate, given the time frame it was thought up - early nineties!

>>
>>Actually VFP can sometimes surprise you in displaying some multithreaded behavior - when you call a function which is a wrapper over API calls to the OS (handling files mostly, e.g. renaming, moving etc), it may report that it's done while it actually isn't. The task is just offloaded to OS's thread.
>
>I would be happy to be surprised, but unfortunate.
>Here is a real world scenario:
>For a slow network, I cache some slow moving data from remote SQL Server, locally to an SQLite database. Initial download of data might be slow. Say:
>Table1 is downloaded in 1 sec, written locally in 0.8 sec
>Table2 is downloaded in 60 sec, written locally in 40 sec
>Table3 is downloaded in 50 sec, written locally in 30 sec
>Table4 is downloaded in 1 sec, written locally in 0.7 sec
>
>Total time is 180+ seconds. I could save at least 60 seconds if I could do this on multiple threads.
>(well this is done once, but you know, still I would like it to be fast)

IIRC the poolmanager thread handling - which on first read should be sufficient for the task - was added in vfp6.
Another "parallel execution" fwk is in vfpx - have only looked at interface, not implementation, as I had thread/activeX based code already in place.