is multi-threading possible?

[kindred]

Hello,

Under VFP 6 SP 5, is it possible to run a process using multi-threading? If so, how?

The reason I'm asking this is i have some processes that might be a bit long and by threading it. It hopefully won't tie of the system.

Under another language I've used it was simply create a thread object and write the code with in that thread object and execute it.

 

[DEDMOD]

VFP programs are all single-threaded. You can get other threads involved, however by using .com objects. I'm not positive, but I think I heard you can multi-thread in VFP 7.

Dave Dardinger

 

[dddenney]

You can build a multi-threaded com component as DEDMOD stated with the following in the Command Window:


BUILD MTDLL MTDLLFileName FROM ProjectName [RECOMPILE]


Lookup BUILD MTDLL in the MSDN Library for more info.

 

[kindred]

Thats a good idea, pretty good work around, but now i think about it, I don't know how effective this would be for my purposes. I'll explain, and maybe some of you have some ideas.

The process is creating an Object out of Outlook.Application (created once when the app is loaded and stored in a custom property of the form), which I then use to access the mapi folders and move messages in the inbox to a sub-folder and if attachments exist, save them out to a place on disk that i've specified.

This process i explained above can sometimes be a process hog and this is what I'm hoping that multi-threading could resolve.

Any of you have thoughts on this? If multi-threading is not the answer, other suggestions would be greatly welcomed.

Thanks,
Stephen

 

[jjgraf]

is this happening on the client side or server side?

If it is on the client side you are telling me all your clients are multi processor.

multi threading only truly helps with more than one processor.

a little more info would help.

where is the app running?

why are you removing the attachments?

do you have your own mail server?

it might be more effective to remove the attachments at the mail server. That is where i do it.

if you do not have a mail server you might talk to your ISP to see if they would remove the attachments then send them in bulk

i'm making the assumption this is for a company and you want to archive the attachments like i do.

justin

 

[fluteplr]

I have not tried this with outlook, but you can sometimes launch events like that with a timer which will allow the rest of your VFP program to keep running. You can then kill the time after the object is created.

 

[kindred]

jjgraf,

The application is run from the client side.

Since when is multi-threading purely only for multi-processors?, I can recall on numerous occasions being able to run a process in the background and surf the net at the same time. This is multi-threading or aka multi-tasking.

The app is running on the client machine, but resides on a production server.

Yes, we do have our own Exchange server, but at this current time, it is not possible to do this at that end for other reasons.

Stephen

 

[kindred]

fluteplr,

What your saying is if i place the code in a timer and then when the timer excutes on the pre-determined time, it will fire the code and still allow for other processes while its processing?

Stephen

 

[jjgraf]

Here is computer Architecture 101 in very general terms

Multi Threading and Multi-tasking are different things.

Multi-tasking is an OS operation. This is simply allows a machine to stop a task and restart another task without fully killing the application. It’s like pausing your VCR and switching to a TV station, then you run the VCR during the commercials.

Multi-Threading is a process by which you break your code into different Sup applications aka(process), lets say you going to do some math.

Machine A with a single Processor app has no Multi-threading:
I'm going to have it do 2+2 = 4 then 2+3= 5
Math 1 goes to the processor it completes then Math 2 goes and completes

Machine A with a single Processor app has Multi-threading:
I'm going to have it do 2+2 = 4 then 2+3= 5
Not lets change things and thread it. Make math 1 Process 1 and Math 2 Process 2
Process 1 which is a Thread goes to the processor. Processor 2 which is a Thread tries to load into the Processor, it is denied because process 1 is still running. When Process 1 completes process 2 is allowed to load into processor.


Machine B with a dual Processor app has no Multi-threading:
I'm going to have it do 2+2 = 4 then 2+3= 5
MATH 1 goes to the processor 0 it completes then MATH 2 goes to processor 0 and completes


Machine B with a dual Processor app Multi-threading:
I'm going to have it do 2+2 = 4 then 2+3= 5
Process 1 which is a Thread goes to the Processor 0.
Process 2 which is a Thread goes to Processor 1

Both processes complete at the same time.

FYI a processor is only able to do one job at a time period.

That is why we have multi processors.


In order to use Multi Threading you Application, OS, and Hardware have to support it.

Windows 98 95 do not support multi-processor.

They do support Multi-Threading which is a process which allows you stop and restart processes without causing problems. Multi-Threading is where a process is a child to the Application which runs in it's own memory space has it's own process id, and can run separate from the rest of the application that started it.

But if you don't have More than 1 processor you gain very little in performance.

As i said it only TRUELY helps with multi-processing

By the way FoxPro does not fully support true multi-threading.


If you want multi-threading learn to love C or Assembly

 

[kindred]

jjgraf,

I wasn't indicating that multi-threading would make the processor run any faster. I was exploring the idea of having an intensive process within foxpro take advantage of multi-threading, thus not allowing foxpro to become a process hog as it can normally do, letting other applications continue on with their process as well.

I should of been more clear, when i said multi-threading and then said multi-tasking, i was looking at it from the user point of view, for a lamen, its the same thing, technically its what you detailed above. The advantage of using something such as a "thread" object if they existed in foxpro would allow for multi-threading at the OS level. It may not be faster, but it would certainly allow for other processes (such as Word) to run by the user at the same time without any noticable slowdown (given only a few applications are running of course).

Let me try and start over and explain what I'm trying to resolve. I have a application that creates an Outlook.Application object when launched (this alone can sometimes take up to a 30 secs or more) and with a timer every 10 minutes it uses that object and accesses the MAPI Folders and then goes on to download attachments that matches a certain criteria. If matched, it downloads all of its attachments to a fileserver of a specific location.

What I'd like to do is remove any intensive processes. I've found the slowdown at the point of accessing the MAPI Folders and also saving out the attachments to disk. My hopes was that multi-threading could resolve this by not allowing foxpro to hog the processor.

Stephen

 

[DEDMOD]

One thing which might help is to put a 'DOEVENTS' in any loop which is taking a lot of time to complete. You might even do something like:

 n = 0
SCAN
   n = n + 1
   *** put your loop code here
   IF n>100
      DOEVENTS
      n = 0
   ENDIF
ENDSCAN

Dave Dardinger

 

[kindred]

thanks, i forgot about DOEVENTS, ill try that

Stephen

 

[CDavis]

It might be that it is not a foxpro problem at all but rather a network issue. If all of your file processing is happening remotely, it might be that the time is being consumed by moving data back and forth over the network. I have an application that is lightning fast when run completely local that turns into a dog when I move components onto the network servers. Maybe other people on the forum will comment on that potential.

--CDavis

 

[ChrisCarroll]

Hi kindred,

I would go something like dddenney's idea of using a separate process, even if the multithreading doesn't actually happen:

If you can put the code to do this stuff in a separate executable, and then call that up asynchronously and minimized (using

Run /N2 AppName

if need be) then you might at least find it gets a smaller slice of the CPU?

Chris

 

[jjgraf]

Threading will not help in what you want to do.

What you mite try is building this into another executable then call it. The calling application will be able to go about what it want's to do.

Since Outlook is a resource intensive application to begin with you will not see the processor come free for another application.

I still say that it would be best to do this on the Exchange server where the data is stored localy, and the User would never suffer any slow down.

You could schedule this task to take place lets say around 12am

 

[ChrisRChamberlain]

Kindred

If you are going to run background processes asynchronously in minimized forms, I suggest you use top level forms and keep the child application as basic and simple as possible.

I have child applications consisting of a top level form only, no main.prg, classes, READ EVENTS, CLEAR EVENTS etc, with one label and one cancel button only.

The Load event sets up the tables/cursors, form and _SCREEN properties, the Activate event runs the code and the Destroy event cleans up.

Some of them weigh in at only 20kb.

The form will need to check through a WinAPI call for another instance of the same form running, and also quit, if applicable, if the parent application is not running.

Multi-Threading in the literal sense it may not be - a workable solution in the real world, it probably would be.

Chris