Best multi-threading solution?

[DatMCEyeBall]

Since AutoIT is single threaded many people have created ways to multithread in AutoIT.

Searching the forums I found many ways to multithread.

So what is the best way to use multi-threading in an autoit script?

Is there anyway to run a function in another thread?

Or compile 2 or more scripts into a single multi-threading .exe?

Edited June 22, 2013 by DatMCEyeBall

[guinness]

Firstly do you understand what "multi-threading" is? Or did your friend tell you that "mult-threading" is the shizzle!?

[czardas]

You can pack a second exe inside the first using FileInstall ==> unpack it ==> run it and I believe you can comunicate with it using >mailslot by trancexx. I haven't tried this with compiled scripts yet.

Edited June 22, 2013 by czardas

[guinness]

How I do it is...

1. Compile a second AutoIt file as an a3x file.

2. Use _RunAu3 (search the Forum)

3. Communicate with the file using WM_COPYDATA (see my signature.)

It's what I do for SciTE Jump, see my signature again.

[KaFu]

In SMF I work with a single command-line switched executable / script. On first start the main process is called, which than runs the program again with certain switches to create worker-instances of itself. Communication is done with a combo of WM_COPYDATA, switches in the SQLite Database and shared memory buffers... additionally I remember seeing examples using mailslots or shared mapped files. So in my opinion there is no "best" solution, all have their pros and cons. Using WM_COPYDATA you can interrupt the current function in the target script, using SQLite gives you persistent memory and using shared memory buffers you can transfer huge amounts of data very fast. Choose the type of inter-script communication which best fits the task at hand.

[JohnOne]

My personal favourite is >this example by GreenCan

[DatMCEyeBall]

The script(s) I'm working on scan your whole harddrive and save the list into a .txt file, this file gets split into memory when you search for something it then continues to look for matches using StringRegExp() and lists them in a listveiw control.

It took about ~5-6 minutes to "index" a 2TB hard drive(It has about 500GB free) and another ~1-2 minutes to search, during this time it only used 50% CPU.

So, if I have 2 threads scanning with a shared index buffer and shared GUI controls, would SQLite be the best solution?

(I seem to use solution in the wrong places, I blame VS Express!)

[Zohar]

On 6/23/2013 at 12:09 AM, KaFu said:

In SMF I work with a single command-line switched executable / script. On first start the main process is called, which than runs the program again with certain switches to create worker-instances of itself. Communication is done with a combo of WM_COPYDATA, switches in the SQLite Database and shared memory buffers... additionally I remember seeing examples using mailslots or shared mapped files. So in my opinion there is no "best" solution, all have their pros and cons. Using WM_COPYDATA you can interrupt the current function in the target script, using SQLite gives you persistent memory and using shared memory buffers you can transfer huge amounts of data very fast. Choose the type of inter-script communication which best fits the task at hand.

What a beautiful idea.

Thank you KaFu

[junkew]

https://www.autoitscript.com/wiki/FAQ number 39

[junkew]

I would be surprised if scanning harddrive multi threaded is quicker then single thread as I make the assumption (never tested it) your harddrive will be the limiting factor.

Maybe test it with findfirstfile/findnextfile and compare for NTFS with FindFirstVolumeMountPoint/FindNextVolumeMountPoint