Thanks Christof I will download your examples and see how I get on.
It has been a while since I looked at any of this multithreading stuff I am
trying to ensure I correctly remember correctly, the difference between:
1). Out-of-process VFP COM server
2). In-process VFP dll
3). Full multithreaded VFP exe
I have to admit that at the moment I cannot see the difference between
running a new thread and an Out-of-process VFP COM server.
For my particular application can you think of any reason why the following
scenario would not work, or of any way it could work better. My application
has three separate components:
1). Port Listener - simple VFP exe (maybe running as a service); there can
only ever be one of these.
2). Virtual Directory traffic manager - Out-of-process VFP COM server; there
will be multiple instances, one for each different virtual directory. Each
of these will be instantiated by the Port Listener and will time-out after a
predefined period if idle.
3). Worker process/thread - In-process VFP dll, each Virtual Directory
traffic manager will create multiple Worker process/threads as required
which once running will remain open to receive further requests unless
timed-out.
In the above scenario would there be any advantage to using your proper
multithreading as opposed to the above?
Your opinions are very much appreciated.
Thanks,
Nick
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Christof Wollenhaupt
> Sent: 26 March 2007 12:43
> To: [email protected]
> Subject: RE: Multithreading - what is the latest
>
> Hi Nick,
>
> Multi-threading in VFP is only possible using the MTDLL runtime. This
> means
> you need at least one COM server that acts as the main program for the new
> thread. To launch an MTDLL in a different thread, you need a little bit of
> C/C++ code which you can download from http://www.foxpert.com/dmult.zip.
>
> Due to the requirement of using a separate DLL for threads there are only
> few differences between multiple threads and multiple process for a VFP
> developer. With multiple threads your application needs less memory and
> you
> can use more and faster interprocess communication means. As far as VFP
> specific resources are concerned (public variables, obejcts, cursors,
> datasessions, etc.) each thread is a completely isolated instance.
>
> > The problem is how to open and control (if necessary) each .exe from the
> incoming 'Listener' application.
>
> I'd use named pipes for that. The server creates the named pipe setting
> the
> number of pipes to PIPE_UNLIMITED_INSTANCES. Then each VFP EXE can open
> the
> other end of the pipe. When the server tries to connect to a pipe, Windows
> automatically searches the list of servers for the next available pipe and
> connects that. On MSDN start reading with the CreateNamedPipe function.
> There's a whole C++ sample for a multi-threaded named pipe server.
>
> --
> Christof
>
>
>
[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.
