Derek, Thanks for your thoughts.
> Although it's possible to use callbacks through FLLs and such I > believe to achieve multi-threading in the same process of VFP, I > believe it's very error prone and likely to cause GPF's due to VFP's > internal memory manager. The only way I accept as a valid VFP > "multithreading" option is to do so multi-process-- create an > out-of-process COM object with a delayed start main thread that does > the work(there's code in the archives on it). We have some production > systems that use this; sadly, the memory requirement for this is kinda > high. Yep, last time I looked at this that was the best way I could find, I just hoped that maybe someone had found a better/easier yet still robust way now. The memory requirement is mainly because the VFP COM wrapper is bloated which is why, especially as I don't need any of the COM functionality, it would be good to do this without the COM overhead. When I said it is entirely in VFP that wasn't strictly accurate I hadn't thought about that answer fully. We are using a small amount of C in an FLL for the callbacks as you mention and for a few other functions that are better done in C than Fox. It is just that all the logic and control is being done in Fox. > Why write it entirely in VFP? Some tools are better sorted to some > things and some are more suited to other things... VFP will not make a > good http web server... Well this is where I kind of disagree. It seems to me that a Web server which is intended mainly to execute VFP code embedded within HTML pages would be best written in Fox. This would be building a Webserver from the ground up in VFP rather than tagging on to some other architecture such as ISAPI were the code execution is effectively an add-on rather than part of the main Kernal. It also allows much greater control of the TCP/IP layer than is otherwise possible. I've got the true multithreading of the incoming and outgoing traffic via Winsock working. It's just finding a way to multithread the VFP code execution part for each separate Virtual directory that I am still working on. Last minute thought. Can I do this by simply running multiple exes; can I call another VFP exe from my main program and have that run in a separate thread? Nick > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Derek Kalweit > Sent: 20 March 2007 19:21 > To: [email protected] > Subject: Re: Multithreading - what is the latest > > > No real alternative here, definitely needs multithreading to do this > task > > properly. > > Although it's possible to use callbacks through FLLs and such I > believe to achieve multi-threading in the same process of VFP, I > believe it's very error prone and likely to cause GPF's due to VFP's > internal memory manager. The only way I accept as a valid VFP > "multithreading" option is to do so multi-process-- create an > out-of-process COM object with a delayed start main thread that does > the work(there's code in the archives on it). We have some production > systems that use this; sadly, the memory requirement for this is kinda > high. > > > > The task at hand is a Multithreaded HTTP Webserver written entirely in > Fox. > > The idea being that each Virtual Directory would have it's own > executable > > (maybe multiple) to marshall the traffic for it's own requests to the > > Winsock layer. That way if the owner of one particular Virtual > directory > > wrote code that locked-up the exe it would only be their own exe that > would > > stop working all others would still be running. > > Why write it entirely in VFP? Some tools are better sorted to some > things and some are more suited to other things... VFP will not make a > good http web server... > > > -- > Derek > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
