Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

In which thread runs a VFP DLL?

Status
Not open for further replies.

Gerrit Broekhuis

Programmer
Aug 16, 2004
316
NL
Hi,

Suppose I create a DLL with VFP9SP2 and get access to the DLL’s code to perform a task. Will this task (from the DLL) run in the same thread or will it get it’s own thread in Windows? I don’t intend to use parallelfox or similar code.

If it can run in another thread I will consider creating a DLL and probably come back with more questions.

Regards, Gerrit
 
Kind of, but not really.

See
It may not become very clear what all this means, but it boils down to this: Usage of multi threaded DLLs you can build in VFP only can provide (limited) multithreading for other clients than VFP itself.
Corrrection: It's not the client using the COM server playing the major role, it's the type of multithreading that's provided by the COM server that makes it unuseful for parallel execution of multiple tasks from one client: The kind of nonblocking multithreaded execution that is provided is for this situation: You have one instance of a COM server that's defined in the VFP MTDLL, two clients can call methods of this same instance. So, first of all, two clients can use the same object, and when this would be from a single threaded DLL two clients calling methods of the COM server object would block each other or the COM server would make one client wait, i.e. one client calls some method and while the COM server executes that method anything else will be queued and run sequentially afterwards. If the COM server object is from an MTDLL one client calls Method1, another client can call the same Method1 or Method2 at the same time from the same COM server instance, this is enabled. No more, no less.

Multithreding in the sense of calling something and copntinue running own process code in parallel within VFP alway requires some hack, not just a COM server that's from a DLL which was compied as MTDLL. The most famous hack once was given by Calvin Hsia in a blog article that I don't find anymore, now. Another hack providing thread creation is in Christian Ehlscheidts with the CreateThreadObject function provided in the vfp2c32.fll

I once wrote thread184-1820019 and you know that as you were the first responder asking for what to use multiprocessing. Seems you're now at a point you know what to use it for. Notice I also pointed out the same Rick Strahl article about VFP multithreading. So there's nothing new to this.

If you still wonder why MTDLL is not allowing multithreading just think about what VFP does in a line using a comserver object - [tt]result = comserver.method(parameters)[/tt] - well, it waits. It doesn't help that this COM server can now still run other clients calls in parallel, it's not running in parallel for you, not because it can't, but because you - the main VFP EXE Process making the call, waits for that call to come back. It doesn't change if the method has no RETURN or you make the call using the syntax prepending an equal sign.

Chriss
 
Hi Chris,

I will (again) look into this as I understand much better why it could be used in my current situation.

Thanks for sharing your information and sample code.

Regards, Gerrit
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top