An idea on multithreading implementation

[Bob Sneidar]

Well my thought was that LC would benefit hugely if 2 or more stacks could be running in their own thread. Take for example an accounting app. Normally you could have the Customer Entry form open, and the Accounts Receivable window open in most well written apps. Sure you could in LC too... so long as one of the windows was not in the process of doing anything, like oh say compiling data for a really large report. 

Under those circumstances, it would not be possible to have LC do this because while that process was going on the other window would be unresponsive. This is one of the things holding LC back from being a true enterprise development environment. 

I dunno, maybe we don't want to go there. But if it were not too much trouble for the dev team to implement some basic form of multithreading on demand, for those who need it, it could be available, and for those who don't, well LC would just run the way it always has. 

Maybe I am using the wrong term here. Often in Windows an application will open multiple instances of an application, and each instance will be it's own process. An explorer window for example is it's own instance of Windows Explorer, and runs on it's own regardless of what the other window is doing. If that is not multithreading, then I am talking about something else. 

Bob


On Jan 18, 2011, at 3:57 PM, Jeff Massung wrote:

> Multi-threading is mutli-threading. The problems exist regardless of the
> format/syntax.
> 
> At the end of the day it comes down to thread safety manipulating properties
> and the most commonly used data control in the toolbox: the field. (This is
> coming from someone who does MT programming all the time). Plus, I don't
> think the average LC developer wants to even -think- about locks, mutexes,
> semaphores, etc. ;-)