Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Why Processing Performance is Not Increasing ?
Message
From
15/02/2014 12:51:14
 
 
To
15/02/2014 12:32:16
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 8
Network:
Windows XP
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01594373
Message ID:
01594413
Views:
48
GUITHREAD is a VFP app. It uses multiple separate processes to handle multi-threading. However, VFP still has limitations when even multiple processes are in use due to the way it uses its own DLLs. These cause issues where sometimes if one app crashes (in a particular way) it will cause the other non-crashed versions of VFP apps to also simultaneously crash.

I am only stating that VFP is not a good tool for multi-threading. It is a fine tool in all regards, including many multi-threading apps. But for high-powered multi-threading (like what you're doing spawning 1700+ jobs per minute) ... it really wasn't designed for that.



>But sir VFP is really nice tool. Though I am novice, but I like to code in it. That is why We all are desperately waiting for the launch of your product Visual Free-pro so that we could have VFP in an advanced Version.
>
>Regards
>
>
>>>Sir, Thank you very Much. I will try both the things tonight and will also try to GUITHREAD and will respond you.
>>>
>>>Thank You
>>>Regards.
>>>Harsh
>>
>>
>One thing that makes GUITHREAD different, is that it actually launches separate processes for each thread. In that way you will not need multiple ps2pdf.dll copies, but rather each .exe that is launched will attach to its own logical copy of the single ps2pdf.dll file.
>
>Having separate processes can make a big difference in parallel performance, and even ease of programming. GUITHREAD basically provides the "glue" necessary to coordinate message systems between the multiple threads. You basically send it numbers, and those numbers equate to commands, and based on those commands you can do anything. Sending it a particular command, and then another number, might instruct a particular thread to open table foo###.dbf and read the instructions from there, a fully customizable solution using whatever makes sense for your app, and so on.
>
>But, Visual FoxPro itself still uses thread blocking for some things ... even in completely isolated processes. It was never written to be a good multi-thread manager, or parallel execution software. It does work, but it is lacking compared to other implementations due to its single-thread original design.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform