|
Home > Archive > FoxPro Help and Support > January 2006 > multi threading/tasking?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
multi threading/tasking?
|
|
|
| I'm going to be building a TCP/IP server application in VFP using the
Catalyst Socket Tools Socket Wrench control. This application will have
to be able to handle multiple clients contacting it at the same time.
VB .net is supposed to be able to do this but I must use VFP (and it
makes sense for other reasons). I'm not really familiar with how VB
..net does this but will VFP at least do whatever VB .net will toward
this goal????
| |
| Stefan Wuebbe 2006-01-07, 7:23 am |
|
"cj" <cj@nospam.nospam> schrieb im Newsbeitrag
news:%23R9NEuwEGHA.3004@TK2MSFTNGP15.phx.gbl...
> I'm going to be building a TCP/IP server application in VFP using the Catalyst
> Socket Tools Socket Wrench control. This application will have to be able to
> handle multiple clients contacting it at the same time. VB .net is supposed to be
> able to do this but I must use VFP (and it makes sense for other reasons). I'm not
> really familiar with how VB .net does this but will VFP at least do whatever VB
> .net will toward this goal????
FoxPro code itself works single-threaded, there is no native
"thread" class like the one in .Net.
You can however implement multi-threading by calling a
customB.EXE from customA.EXE several times or by creating
COM server Exe/DLLs, which in turn can be controlled by a Web
server like Microsoft's IIS or Apache.
See also
http://msdn.microsoft.com/library/d...tithreading.asp
and Rick's site, e.g.
http://www.west-wind.com/search_sim...hreading
or Remus' example at
http://www.geocities.com/rremus/multithreaded_vfp.htm
or Michail's at
http://vfpdev.narod.ru/util_e.html - tsthread.zip
hth
-Stefan
--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------
| |
|
| That's a lot to understand for me. I've actually never done this in VB
..net either. Do you believe it is possible, more to the point practical
to develop a server application in VFP that can handle multiple client
connections at the same time?
Stefan Wuebbe wrote:
>
> "cj" <cj@nospam.nospam> schrieb im Newsbeitrag
> news:%23R9NEuwEGHA.3004@TK2MSFTNGP15.phx.gbl...
>
> FoxPro code itself works single-threaded, there is no native
> "thread" class like the one in .Net.
>
> You can however implement multi-threading by calling a
> customB.EXE from customA.EXE several times or by creating
> COM server Exe/DLLs, which in turn can be controlled by a Web
> server like Microsoft's IIS or Apache.
> See also
> http://msdn.microsoft.com/library/d...tithreading.asp
>
> and Rick's site, e.g.
> http://www.west-wind.com/search_sim...hreading
> or Remus' example at
> http://www.geocities.com/rremus/multithreaded_vfp.htm
> or Michail's at
> http://vfpdev.narod.ru/util_e.html - tsthread.zip
>
>
> hth
> -Stefan
>
>
>
| |
| Olaf Doschke 2006-01-16, 8:25 pm |
| > Do you believe it is possible, more to the point practical to develop a
> server application in VFP that can handle multiple client connections at
> the same time?
In your case it's not VFP that handles connections, but that
Catalyst Socket Tools Socket Wrench control you want or have
to use.
VFP itself has no sql server component clients need to connect to,
the clients kind of act as their own server each. Locking is handled
via the filesystem and in general you share access to databases /
tables with shared file access.
You can create a VFP COM server, which must not be
confused with but could act as a SQL server or an
application server.
See the chapter "Working with automation servers",
especially read the topic "Scalability and Multithreading",
which introduces you to the topic "Controlling Call Blocking".
in the VFP help.
But if you don't have a server component you won't
introduce a bottleneck to the clients at all. That is the
advantage of file based databases like vfp.
Of course this also has it's downside, eg file corruption
risks that rises with the number of clients accessing the
same data at the same time. But with the usual precautions
like backup/restore, data maintainance (reindex/pack)
VFP is a rather stable and fast database.
I wonder, if you could do what you want to without that
socket wrench control. This may cover security, but
otherwise VFP is not accessed via some socket, where
a server wait's for calls like a MySQL database.
Bye, Olaf.
| |
|
|
|
| Yes, I was talking about TCP/IP. I'll look over the references you gave
me. Thank you, I appreciate your help.
Olaf Doschke < T2xhZi5Eb3NjaGtlQFNl
dG1pY3MuZGU@strconv.14 wrote:
> If you meant internet with TCP/IP, also take a look at this
> article, especially the part about "Data access over TCP/IP"
> and the part "Distributed applications"
>
> http://www.west-wind.com/presentati...netenabling.htm
>
> Bye, Olaf.
>
>
| |
| Olaf Doschke 2006-01-17, 11:24 am |
| > Yes, I was talking about TCP/IP. I'll look over the references you gave me. Thank you, I appreciate your help.
Well, TCP/IP is the protocoll used in the internet,
but it's not exclusively used there. You can also have
a LAN configured to use the TCP/IP protocoll.
You may have rang other peoples bells if you
would have been more specific and used terms
like "distributed application", "fat client" or at
least "internet".
I'm not sure what you need to achieve right now,
but the west-wind web page covers many different
solutions of which one should fit your needs.
Bye, Olaf.
| |
|
| I've been asked to write a server application specifically in VFP that
opens a port and listens for one line strings from clients. These
strings contain info that is used in lookups and calculations on a
centrals database or databases (not all the specs are available yet) and
then a response one line string is sent back to the client.
I was also told to use Socket Wrench to facilitate listening on the
port, instigating sockets and reading and sending the strings. My
biggest concern is that this server will be receiving strings non-stop
from multiple clients and I can only assume many will come in at the
same time.
I've never written a program that could handle multiple conversations.
I've never written a program that used TCP/IP
I've only written 2 small VFP programs and none used Socket Wrench.
I'm a long time programmer but I've been writing stand alone programs
using VB4 and DOS based Clipper. I'm fighting a seemingly huge learning
curve. And I've got to figure this out.
I'll keep reading. Right now I have a tiny program that listens to a
port accepts the connection from 1 client and echo's back any string
that it's sent. Written in VFP.
Olaf Doschke wrote:
> Well, TCP/IP is the protocoll used in the internet,
> but it's not exclusively used there. You can also have
> a LAN configured to use the TCP/IP protocoll.
>
> You may have rang other peoples bells if you
> would have been more specific and used terms
> like "distributed application", "fat client" or at
> least "internet".
>
> I'm not sure what you need to achieve right now,
> but the west-wind web page covers many different
> solutions of which one should fit your needs.
>
> Bye, Olaf.
>
>
| |
|
| cj wrote:
> I've been asked to write a server application specifically in VFP that
> opens a port and listens for one line strings from clients. These
> strings contain info that is used in lookups and calculations on a
> centrals database or databases (not all the specs are available yet) and
> then a response one line string is sent back to the client.
>
> I was also told to use Socket Wrench to facilitate listening on the
> port, instigating sockets and reading and sending the strings. My
> biggest concern is that this server will be receiving strings non-stop
> from multiple clients and I can only assume many will come in at the
> same time.
Hi cj,
It is not necessary to use multiple tasks to handle multiple
connections. But you may have to code your program in a 'statefull'
way. i.e. try not to take too long processing each connection.
See if your socket library has a Select() function.
--
Paul
| |
| Olaf Doschke 2006-01-17, 1:24 pm |
| > I've been asked to write a server application specifically in VFP that opens a port and listens for one line strings from clients.
> These strings contain info that is used in lookups and calculations on a centrals database or databases (not all the specs are
> available yet) and then a response one line string is sent back to the client.
OK. Depending on the protocol you use this could be called
webservice, webserver but more likely will be somthing very
proprietary just for that application.
So far I see no problem.
> I was also told to use Socket Wrench to facilitate listening on the port, instigating sockets and reading and sending the strings.
> My biggest concern is that this server will be receiving strings non-stop from multiple clients and I can only assume many will
> come in at the same time.
OK. VFP itself does not offer anything for port listening. You could
also use the winsock control, but that is not recommandable for many
incoming requests.
As the Socket Wrench control is third party I can't say much about it.
That control should be the mission critical component which has to
handle queueing requests. It may be better to have a real webserver
(IIS) handle the requests as an interface to the VFP component running
inside. That way you can rely on the known stability and capacity of the
webserver.
> I'm fighting a seemingly huge learning curve. And I've got to figure this out.
This is not the easiest thing to start with, true. You came the right place
to look for help. Some other places you may visit are:
http://www.universalthread.com
http://fox.wikis.com
http://www.tek-tips.com
A specialist in web related things is - as I already recommended:
http://www.west-wind.com
You'll certainly find more sites starting from there.
> I'll keep reading. Right now I have a tiny program that listens to a port accepts the connection from 1 client and echo's back
> any string that it's sent. Written in VFP.
Sounds like you are a quick learner, congrats.
So why not make a stress test and have several client apps send
endless requests to your simple server.
You may also find help in the samples that come with VFP, especially
in the subfolder samples\servers of VFP's program folder:
CD (Home()+"samples\servers")
Bye, Olaf.
| |
|
| I don't see a select function. What would it do? Perhaps they call it
something else.
Paul wrote:
> cj wrote:
>
> Hi cj,
>
> It is not necessary to use multiple tasks to handle multiple
> connections. But you may have to code your program in a 'statefull'
> way. i.e. try not to take too long processing each connection.
>
> See if your socket library has a Select() function.
>
| |
|
| I've been looking at
http://www.west-wind.com/presentati...netenabling.htm
and I already don't understand. I asked our resident VFP expert who
said they're trying to do something funky and just use Run. I want to
understand this. I undertand the first 4 lines. Can you explain the
rest for me?
FUNCTION ShellExec
LPARAMETER lcLink, lcAction, lcParms
lcAction = IIF(EMPTY(lcAction),
"Open", lcAction)
lcParms = IIF(EMPTY(lcParms), "", lcParms)
DECLARE INTEGER ShellExecute ;
IN SHELL32.dll ;
INTEGER nWinHandle, ;
STRING cOperation, ;
STRING cFileName, ;
STRING cParameters, ;
STRING cDirectory, ;
INTEGER nShowWindow
DECLARE INTEGER FindWindow ;
IN WIN32API ;
STRING cNull,STRING cWinName
RETURN ShellExecute(FindWin
dow(0, _SCREEN.caption), ;
lcAction, lcLink, ;
lcParms, SYS(2023), 1)
Olaf Doschke wrote:
> OK. Depending on the protocol you use this could be called
> webservice, webserver but more likely will be somthing very
> proprietary just for that application.
>
> So far I see no problem.
>
>
> OK. VFP itself does not offer anything for port listening. You could
> also use the winsock control, but that is not recommandable for many
> incoming requests.
>
> As the Socket Wrench control is third party I can't say much about it.
> That control should be the mission critical component which has to
> handle queueing requests. It may be better to have a real webserver
> (IIS) handle the requests as an interface to the VFP component running
> inside. That way you can rely on the known stability and capacity of the
> webserver.
>
> This is not the easiest thing to start with, true. You came the right place
> to look for help. Some other places you may visit are:
>
> http://www.universalthread.com
> http://fox.wikis.com
> http://www.tek-tips.com
> A specialist in web related things is - as I already recommended:
> http://www.west-wind.com
>
> You'll certainly find more sites starting from there.
>
> Sounds like you are a quick learner, congrats.
> So why not make a stress test and have several client apps send
> endless requests to your simple server.
>
> You may also find help in the samples that come with VFP, especially
> in the subfolder samples\servers of VFP's program folder:
> CD (Home()+"samples\servers")
>
> Bye, Olaf.
>
>
| |
| Christian Ehlscheid 2006-01-18, 3:24 am |
| Hi,
that not going to be easy with pure VFP code,
the problem is that VFP is single threaded.
A typical server application that can handle multiple connections at the
same time normally has a main thread running which listens on a
specified port and then spawns a new thread/ use a thread from a thread
pool which will accept the connection request and handle it.
This cannot be programmed in pure VFP.
I would use C/C++, C#, VB Net or another COM aware language for the main
thread - spawn worker threads from there which will accept the
connection, instantiate a VFP COM object, call a method on that COM
object which does the actual processing of the data and return the
result which should be send back to the client.
In this scenario you would use the features of each language, C(++), C#
for threads and VFP for it's easy of data manipulation.
Regards
Christian
| |
|
| Christian Ehlscheid wrote:
> Hi,
>
> that not going to be easy with pure VFP code,
> the problem is that VFP is single threaded.
>
> A typical server application that can handle multiple connections at the
> same time normally has a main thread running which listens on a
> specified port and then spawns a new thread/ use a thread from a thread
> pool which will accept the connection request and handle it.
>
> This cannot be programmed in pure VFP.
Not all servers work this way. There are plenty of (admittedly written
in C) web servers that run as a single task.
Actually thinking about CJ problem it would probably be better/easier to
use webservices. i.e. create a COM object in VFP and use IIS to handle
the connections.
CJ: How will the clients be connecting? HTTP? Or are you using a
proprietary protocol?
Any chance they're using XML to communicate? SOAP is really easy to
handle in VFP...
--
Paul
| |
|
| TCP/IP I guess. I'm using Telnet to test the program. How does Telnet
connect?
Paul wrote:
> Christian Ehlscheid wrote:
>
> Not all servers work this way. There are plenty of (admittedly written
> in C) web servers that run as a single task.
>
> Actually thinking about CJ problem it would probably be better/easier to
> use webservices. i.e. create a COM object in VFP and use IIS to handle
> the connections.
>
> CJ: How will the clients be connecting? HTTP? Or are you using a
> proprietary protocol?
>
> Any chance they're using XML to communicate? SOAP is really easy to
> handle in VFP...
>
| |
| Christian Ehlscheid 2006-01-18, 9:24 am |
| > Not all servers work this way. There are plenty of (admittedly written
> in C) web servers that run as a single task.
Yes, but a single threaded design definitly will not scale well.
If the work that has to be done on each client request is really tiny
(so that it can be executed a million times per second) then a single
threaded design may be ok. But if the possibility exists that a single
request blocks the main thread a bit longer than you won't get around a
multi thread or multi processes design where the main thread is only
responsible for accepting connection's and distribute the request to
independent threads/processes.
Since CJ wants to use FoxPro I think he'll definitly wants to query some
data out of tables on each request and for this a single threaded
design isn't adviseable.
Regards
Christian
| |
| Olaf Doschke 2006-01-18, 9:24 am |
| Hi cj,
> TCP/IP I guess. I'm using Telnet to test the program. How does Telnet connect?
Well, TCP/IP is a low level protocol
HTTP, TELNET, FTP, GOPHER etc. are high level protocols on top of that,
more or less "high level".
Even if you might test with telnet, as far as I
understand you, you want to use a proprietary protocol,
so basing your server on a webserver is not what you
want or need.
I've taken a look at the Catalyst SocketWrench control.
It bases on Winsock2 (ws2_32.dll), as far as I understand.
In it's Listen-Event that control has a parameter Backlog,
which "specifies the maximum size of the queue used to
manage pending connections". So there you are: The control
handles the connections, nothing you have to worry about
within your VFP component.
As you use a proprietary protocol (that is defined by the strings
you receive at your server/socket and the strings you send back)
you could handle more traffic than using IIS as a base, as your
protocol may be much shorter than the typical HTTP 1.0 headers
eg. Maybe ok, if that control is stable.
Bye, Olaf.
| |
| Olaf Doschke 2006-01-18, 9:24 am |
| > Since CJ wants to use FoxPro I think he'll definitly wants to query some data out of tables on each request and for this a single
> threaded design isn't adviseable.
That is true, but maybe using a multithreaded COM-Server DLL
for that purpose would be sufficient. Starting several instances
of a VFP.EXE = worker threads may also work, see the
proposed use of ShellExecute in the other branch of this thread
(newsgroup thread that is).
Bye, Olaf.
| |
| Olaf Doschke 2006-01-18, 9:24 am |
| >I undertand the first 4 lines. Can you explain the rest for me?
Well, that is going into details, which I can't sort
into the big picure..., but nevertheless:
> DECLARE INTEGER ShellExecute ;
....
> DECLARE INTEGER FindWindow ;
> IN WIN32API ;
> STRING cNull,STRING cWinName
These are two declarations of Windows API
functions. Descriptions of what these do can be
found in the MSDN (http://msdn.microsoft.com/library)
> RETURN ShellExecute(FindWin
dow(0, _SCREEN.caption), ;
> lcAction, lcLink, ;
> lcParms, SYS(2023), 1)
returns the returnvalue of a ShellExecute call,
that is something rather similar to RUN.
Instead of FindWindow, Id say simply use
_SCREEN.hwnd ;-), VFP does not need to
find itself....
lcLink is the app that is started within the directory SYS(2023),
which is the temp dir (getenv("temp")).
A guess of putting that in the big picture is, your VFP
expert suggests two components, one listening for connections,
and the other (or several others, as lcLink can differ) that are
executed with ShellExecute.
What did you ask him to get that answer?
But as said initially, that details may not matter if you
choose what I'd suggest now, as the rough design
of your server:
a) some Socketlisterner.EXE
which waits for connections using the SocketWrench control,
reads in the requests, calls/instanciates b) and returns the results.
b) some mutithreaded COM server DLL (VFPServer.DLL)
that is called from a) via instanciation of COM classes. There
you have the multithreaded VFP component.
Then the bridge between a) and b) is neither RUN nor
ShellExecute but CREATEOBJECT("VFPServer.DataClass")
or whatever you call your comserver (maybe even several com
servers each for special purposes). And each CREATEOBJECT
will create a new thread within the DLL process of the comserver
DLL.
Bye, Olaf.
| |
| JohnnyCinco 2006-01-18, 8:25 pm |
| Ok .
This is as far as I had to read.
What you need is a SERVER SIDE VFP TYPE WEBSERVER.
You can run VFP applications through TCP/IP.
It is called ACTIVE FOXPRO PAGES. It is a similitude to ASP except it is
all Fox Pro.
Go here and read up and enjoy....
http://www.afpages.com/
Johnny
"cj" <cj@nospam.nospam> wrote in message
news:%231xBLq3GGHA.532@TK2MSFTNGP15.phx.gbl...[color=darkred]
> Yes, I was talking about TCP/IP. I'll look over the references you gave
> me. Thank you, I appreciate your help.
>
> Olaf Doschke < T2xhZi5Eb3NjaGtlQFNl
dG1pY3MuZGU@strconv.14 wrote:
| |
| Olaf Doschke 2006-01-18, 8:25 pm |
| > What you need is a SERVER SIDE VFP TYPE WEBSERVER.
> You can run VFP applications through TCP/IP.
>
> It is called ACTIVE FOXPRO PAGES. It is a similitude to ASP except it is
> all Fox Pro.
>
> Go here and read up and enjoy....
>
> http://www.afpages.com/
I know, it's a german product :)
Nevertheless, AFP is a scripting language used within a webserver,
not a webserver itself. You can combine VFP code with HTML.
Like you said: It's a similtude to ASP. ASP is also no server.
But you are having the overhead of a HTTP server and the HTTP protocol,
then the AFP component processing the AFP script. AFP is fine for
webapplications you want to write using VFP.
If eg all you want to send in is requests like
company=12389743
and get back results as
ACME Ltd.
Then you don't need the overhead of the HTTP request and
response header.
cj fears heavy traffic to this service. That alone may justify the
low level development of a server. If the requests are as simple
processed as using a table, seeking a record, returning some
field, then the query process would need less time as all the
protocol overhead. Of course that argument fails if the querys
of VFP data get more complicated. Then the http protocol
overhead may contribute few percent of the roundtrip time.
It's true that AFP can handle pretty heavy loads, but cj has
not stated any figures to be expected. As I already critizied
he's giving very specific details already without outlining the
big picture.
Of course it will save lots of development time using a webserver
and AFP, if you want to access VFP data over the internet
(or intranet). You can concentrate development efforts on the
scripts querying the data. Not managing connections, blocking
IP adresses, care for denial of service attacks etc pp.
And to handle more traffic than one server alone may handle
there is also the possibility to have a server pool of many
webservers.
On the other side I've played around with the Freeware Edition
of the socketwrench control and must admit, it's even easier than
using the MS winsock ActiveX control. The idea of Catalyst
is to have one socket control as a listener, creating worker
socket controls for each connection, reusing inactive controls
of disconnected clients. I haven't stress tested it, at least with a
few connections that works just fine. The concept of one ActiveX
control per connection, each calling an instance of a vfp exe or
com server dll may loose against AFP, true.
Bye, Olaf.
| |
| Christian Ehlscheid 2006-01-19, 7:24 am |
| Hello Olaf,
i'm a bit confused.
> a) some Socketlisterner.EXE
> which waits for connections using the SocketWrench control,
> reads in the requests, calls/instanciates b) and returns the results.
>
> b) some mutithreaded COM server DLL (VFPServer.DLL)
> that is called from a) via instanciation of COM classes. There
> you have the multithreaded VFP component.
>
> Then the bridge between a) and b) is neither RUN nor
> ShellExecute but CREATEOBJECT("VFPServer.DataClass")
> or whatever you call your comserver (maybe even several com
> servers each for special purposes). And each CREATEOBJECT
> will create a new thread within the DLL process of the comserver
> DLL.
I think you're wrong here.
CREATEOBJECT'ing a VFP COM DLL that is compiled for multithreaded
use within a normal VFP EXE don't makes the VFP EXE multithreaded.
e.g. (pseudocode of exe)
loObj = CREATEOBJECT('someVF
PComObject.Class')
loObj2 = CREATEOBJECT('someVF
PComObject.Class')
loObj.someMethod()
loObj2.someMethod()
will run serially all on one thread, the main VFP exe thread.
Compiling a VFP COM DLL for multithreaded use just means that the object
can be run on different threads. But the object never creates it's own
thread.
To do what you described above one has to somehow create threads on
which the Object methods are called.
For example with the the Component from
http://www.geocities.com/rremus/multithreaded_vfp.htm
Regards
Christian
| |
| Olaf Doschke 2006-01-19, 9:24 am |
| > loObj. someMethod()
> loObj2.someMethod()
>
> will run serially all on one thread, the main VFP exe thread.
That's true. You are right to be confused.
I thought wrong again. We already discussed
that issue, right.
Nevertheless I assume the socket controls
(one for each connection) will introduce a
thread each and run parallel, so the blocking
call to the vfp com server isn't crucial, as it
happens in the socket control thread, not
the main vfp server thread.
Of course the benefit of using a multithreaded
com server dll can be questioned then, as you
may even call some native VFP object, because
you are right that a method call blocks the calling
thread to continue and start that same method
or some other of a second com object. Still these
objects run in seperate threads each (you can
see that there will only be one DLL process
listed in the task manager). The blocking happens
in the calling thread.
Bye, Olaf.
| |
| Christian Ehlscheid 2006-01-19, 9:24 am |
| Hi,
> Nevertheless I assume the socket controls
> (one for each connection) will introduce a
> thread each and run parallel, so the blocking
> call to the vfp com server isn't crucial, as it
> happens in the socket control thread, not
> the main vfp server thread.
This is also not possible in VFP :)
Com object methods and events always execute in the thread they were
created in (at least in VFP).
Objects may spawn other threads in the background and fire events from
there, but the code in the eventhandlers (set up with EVENTHANDLER()
method) always runs in the main VFP thread.
And since events are the place where you normally have to put your code
we're back at the blocking issue.
Regards
Christian
| |
|
| Olaf, wasn't it you that recommended I look at that link? All I mean is
that it's over my head and apparently that of the other programmers here
as well.
Thanks again to everyone for the help on this thread, I didn't want to
leave you hanging or thinking I didn't appreciate the help but I'm not
going to be reading this thread any more, I have to do some other stuff.
When I need something else I'll post a new thread.
cj
Olaf Doschke wrote:
>
> Well, that is going into details, which I can't sort
> into the big picure..., but nevertheless:
>
> ...
> These are two declarations of Windows API
> functions. Descriptions of what these do can be
> found in the MSDN (http://msdn.microsoft.com/library)
>
> returns the returnvalue of a ShellExecute call,
> that is something rather similar to RUN.
> Instead of FindWindow, Id say simply use
> _SCREEN.hwnd ;-), VFP does not need to
> find itself....
>
> lcLink is the app that is started within the directory SYS(2023),
> which is the temp dir (getenv("temp")).
>
> A guess of putting that in the big picture is, your VFP
> expert suggests two components, one listening for connections,
> and the other (or several others, as lcLink can differ) that are
> executed with ShellExecute.
>
> What did you ask him to get that answer?
>
>
>
> But as said initially, that details may not matter if you
> choose what I'd suggest now, as the rough design
> of your server:
>
> a) some Socketlisterner.EXE
> which waits for connections using the SocketWrench control,
> reads in the requests, calls/instanciates b) and returns the results.
>
> b) some mutithreaded COM server DLL (VFPServer.DLL)
> that is called from a) via instanciation of COM classes. There
> you have the multithreaded VFP component.
>
> Then the bridge between a) and b) is neither RUN nor
> ShellExecute but CREATEOBJECT("VFPServer.DataClass")
> or whatever you call your comserver (maybe even several com
> servers each for special purposes). And each CREATEOBJECT
> will create a new thread within the DLL process of the comserver
> DLL.
>
> Bye, Olaf.
>
>
| |
| Olaf Doschke 2006-01-19, 11:24 am |
| > Olaf, wasn't it you that recommended I look at that link?
Well, ok, now I see. The article is much longer isn't it?
And the interesting parts come later...
eg:
-Data access over TCP/IP
-Reaching out over the network with DCOM
-Distributed applications / Data Access over HTTP
> When I need something else I'll post a new thread.
Okay. Thread closed ...
Bye, Olaf.
| |
| Olaf Doschke 2006-01-19, 11:24 am |
| > Objects may spawn other threads in the background and fire events from there
The Socketwrench control surely must do so. Calling the Listen()-method
must start some listening thread, eg.
> but the code in the eventhandlers (set up with EVENTHANDLER() method) always runs in the main VFP thread.
Okay, if you
DEFINE CLASS myEventhandler
IMPLEMENTS...
....
and bind to the events with EVENTHANDLER(oSocket
Wrench,oEventhandler
)
then the events will be handled in the VFP object and therefor run in the same thread.
But I did create a class in a vcx based on Olecontrol and choose the catalyst
socketwrench control. In this class I added code in the methods and events of the
control. I don't know if this is only the visual counterpart to the definition of an
eventhandler as a prg class. I will see if this runs in a spawned thread or not.
Bye, Olaf.
| |
| Olaf Doschke 2006-01-19, 8:25 pm |
| > But I did create a class in a vcx based on Olecontrol...
>...I will see if this runs in a spawned thread or not.
Ok, I saw it: It didn't work.
Perhaps DDE would be a way, like wOOdy and Thomas
Ganss often suggest when it comes to MT and callbacks.
Bye, Olaf.
|
|
|
|
|