Greg,

your use case sounds well suited for throwing more cores at the problem. That said, it lies between the needs Rick has running a server process and the tasks I often struggle with, calculations taking more than a couple of milliseconds on very large groups of data. I also have not looked at most of the other tools en detail, esp. if the tools allows to spawn to the cores of other machines available on the network.

I often use a simpler approach to throw HW at such problems well suited to vfp:
All tasks are records in a tasks table with a field for task status
A program runs over that table looking for the next problem with status not started,
starts that task, changes status to working
when done updates the task record to done if status is working
if no "not started" records exist, look for "working" records
when done updates the task record to done if status is working
until all task records are done.

It that task table is somewhre on the network, I can hook all idle machines to the task by executing as many processes of the working vfp program on the machine as it has free cores, usually via batch file. Can be done manually if you want some cores for user browsing the net or similar...

Works well enough ;-))



>You make some vary good points. I will expand my search. The only reason I am investigating this is to enhance the single-threaded FUnit application. Because currently, when run a smoke test against, say, my Query tool, it takes over two minutes to complete the hundreds of test cases. I thought that if I could execute the tests in parallel they could complete it far fast. Make the test runs more inviting to be run more often during the development phase.
>
>Thank for the suggestions.
>
>>There are lots of ways that you can run multi-threaded FoxPro code, but they all require some sort of wrapper - typically via COM - to provide the callback mechanism from the multi-threaded code.
>>
>>You can also call into external multi-threaded code from FoxPro. So you can call out to .NET code that spawns new threads and those threads can then fire back information to FoxPro either using events or even something as simple as object references that are passed in and called from the multi-threaded code. If you're familiar with .NET this is a great option for interacting with multi-threaded code.
>>
>>For example, Web Connection includes a ThreadRunner class that includes both C++ and .NET components that provide a wrapper around this mechanism. The Fox code calls out to Win32 or .NET to spin up a new thread and you pass in an object via COM. This library is geared towards an event based flow that has start/progress/complete/cancel/fail events that can be fired and received back at the FoxPro caller along with the ability to wait for all events to complete which is the most common scenario for async/multi-threaded code.
>>
>>In this scenario, you basically provide an object that is passes to the multi-threading handle (.NET or Win32) which then fires events back as needed. There's even a generic component that can execute a PRG file directly from a multi-threaded call. It's not difficult to do this and a library can wrap this fairly easily. Typically COM is used to provide the connector that can then call back into FoxPro and execute Fox code. However, the easiest way is to just pass an object into a pipeline that can then fire events back into FoxPro to message. For me I've been using .NET objects to do this and it works great.
>>
>>THere are of course other libraries that do similar things - the most popular being ParellelFox which is a more generic choice. ThreadRunner is more useful for Web and Async execution scenarios.
>>
>>Either way - there are lots of ways to do this with FoxPro.
>>
>>OTOH, if you are really in need of multi-threaded code, maybe it's time to investigate other technologies that can run multi-threaded code without extra components and acrobatics to work around FoxPro limitations :-)
>>
>>+++ Rick ---
>>
>>
>>
>>>As I understand it, the whole point of multithreading - well, one of the points - is to allow different processors or cores to share the workload. I am not sure how you implement multithreading in Visual FoxPro, though, since it doesn't have any built-in multithreading capability. At least, none that is exposed to the programmer.