>>>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)
>
>Hmm... how about launching any number of vfp.application objects and delegating the task to them - not sure whether they'd execute in the same thread. Wouldn't that be an out-of-process COM object?

See my reply to Cetin - doable, but not even close to promises and even further away from asynch await.