>>>I wasn't concerned with speed that much - just wanted to know whether the load would be spread.
>>
>>Yupp it should. But make sure the "load" mostly taxes the cpu, or you can have contention on already bottlenecked parts: 2 processes querying a table via phone line won't help<g>. In the very worst case you might actually slow down compared to processing singlethreaded if you tip caches already running near capacity over into thrashing. Happened on relatively memory starved machines on disk intensive routines - but is the exception and not the rule. I am sure both of you can visualize similar scenarios, even if I don't get into detail here.
>
>Sure, we're talking about processor load only, of course, since everything else is pretty much shared. I had in mind the typical scenario with VFP web apps, where you'd offload the creation of lengthy reports to a queued exe, so the main app running the web server wouldn't take too long to respond. I assume these two would naturally go to different cores (or should be tweaked to do so if they don't by themselves).
>
>But as you say, we can have various scenarios here, including the fight between the twins.

All in all such approaches work great as long as you find ways not to bother with managing them - but which is typical case shown by poolmanager et al. Best are the fire and forget-scenarios like your report, but recently I have been very lucky with pre/selforganizing parallell tasks via task/semaphore table. Much better than trying to control the different processes - typically I have a minimal prg checking the task table and OLE-automate the intensive tasks. COM is great as long as you can stay on a few machines without installation/config troubles.

>Seems to be one of those things where the automatic settings are too good to tweak, i.e. the time wasted on tweaking and testing never materializes in a serious performance gain.

Well said.

regards

thomas