>>
>>Every process contains at least one thread, and all code executes on a thread. You can't separate the two. A process is one or more threads with its own memory space and resources isolated from other processes. One or more threads can exist within a process and share those resources (the degree to which this can be done in VFP is limited), but there is always at least one thread. Windows schedules processor time for each thread, but those threads will execute in parallel whether the threads come from one process or multiple processes. So, yes, VFP processes run just like threads because they contain threads, and that includes HyperThreading.
>>
>>The ParallelFox examples demonstrate that tasks run in parallel. In the Windows Task Manager, you will see that the "before" examples use the equivalent of one core (on a quad core machine, CPU usage is 25%). The "after" examples use 100% of the CPU (or close to it) and the examples take less time to execute. As I mentioned in the blog, those examples don't work well with HyperThreading.
>
>Thanks! I'm assuming you're using something like setting the processor affinity to assign to the processes. Does this work for the virtual processors you have with hyper-threading too??

No. In fact, setting CPU affinity is discouraged unless you specifically need it. Open Windows Task Manager Performance tab, and you'll see even a single-thread gets spread across multiple cores (although code still runs sequentially). I believe CPU execution is scheduled per instruction (or close to that), and setting CPU affinity can get in the way of that. In other words, let Windows and the CPU do its job and balance execution of all processes, unless you need it to do something different. That said, setting affinity can be beneficial in some circumstances, so if there is a demand for it, support for it may be added to a future release. In the meantime, I think it can be done with the Windows API.