34 replies to this topic

[Excalibur]

Perhaps im spoiled by higher level languages, but i love using the AutoIt... until i needed to do two things at once. :-(. Threads would be awesome, also a tutorial on how others could make their own plugins or something of the sort, or perhaps i missed it? Perl is huge because people could write alot of their own functions if perl didnt already have a support for it. Personally i like AutoIt because its so easy to handle other applications, possibly i am wanting to stretch original intention a bit too far. :-P... but hey... look what happened to C. rofl. :-P

[w0uter]

i would love autoit to be multithreaded.
but thats probly not gonna hapen any time soon.
(maby in autoit v4/5 ?)

till then you can use AdLibEnable.

[Nutster]

Hmm... I would like multi-threading too. Now how to do it, so each thread behaves indepentently? That will be discussed in the developers forum.

What kind of interface do you have in mind?

[Valik]

I don't think threading is such a good idea. Nothing (internally) is prepared for a multi-threaded environment. To try to add in threading support now (in any form) would require significant rewriting of the core AutoIt code. Personally, I do not want to go through an extended period of time where AutoIt is completely broken while regressions from implementing threading support are fixed; I get annoyed enough as is when minor regressions cause my scripts to stop working. The current core, although only single threaded, has not be drastically changed in one big shot like it would take to implement multi-threading. So basically, its not broke so lets not break it adding a feature that was never meant to be implemented.


That is my technical standpoint. My opionated standpoint based on my experience with C++ is that multi-threading is rarely needed. I can just see some of the idiotic code that will be produced by the forum-morons trying to use multi-threading where it is not needed. I continue to go back to the Call() function when I want to point out that a lot of users really don't have enough sense to be using AutoIt. Its constantly misused as the primary method for invoking user functions. If people can't manage to figure out how to call a function, do they really need access to threading support?

I think that of these two points, the first should hold the most merit. Like adding object-oriented support, multi-threading is one of those things that needs decided on before writing the first line of code because supporting features like that require conscious development decisions that permeate throughout the entire application. You don't simply come along later and just add it in without either breaking everything already written or rewriting everything (Which will probably lead to breakage, too).

[Nutster]

That was more or less my conclusion as well, after thinking about it for a while. A lot of internal structures that are together right now would need to be seperated (thinking about AutoItScript, probably the largest class in the whole program) so that each thread can have its own variables and process tree. This is not going to be simple. Sorry guys. This will have to wait a while, maybe version 4.

[blindwig]

I used to do a thing with BAT files, where I would have a master BAT file that would START several other BAT files, each of which would log on to a server and get some data and log it to a file. The master BAT file would loop waiting for all the sub-BATs to log their data, and then concatenate it to a master log file. I guess you could call this a primative form of multi-threading (since I used START instead of START /WAIT).
I guess AutoIt could do something similiar, just distribute several EXEs and run them using RUN (instead of RUNWAIT) and have some sort of system for them to communicate with the master script.

[FuryCell]

I used to do a thing with BAT files, where I would have a master BAT file that would START several other BAT files, each of which would log on to a server and get some data and log it to a file.  The master BAT file would loop waiting for all the sub-BATs to log their data, and then concatenate it to a master log file.  I guess you could call this a primative form of multi-threading (since I used START instead of START /WAIT).
I guess AutoIt could do something similiar, just distribute several EXEs and run them using RUN (instead of RUNWAIT) and have some sort of system for them to communicate with the master script.

<{POST_SNAPBACK}>

You have command line parimeters and restart the script the in a different mode like this little script i made today.
This is good becuase you don't have to have multi exes which makes the distribution size smaller.
http://www.autoitscript.com/forum/index.php?showtopic=13190

Edited by SolidSnake, 04 July 2005 - 01:36 PM.

[layer]

At least it's a possibilty in v 4.

[quaizywabbit]

what if keywords such as "ThreadStart" and "ThreadEnd" were introduced where the Autoit.exe was opened in an additional instance during that "Thread"? the code between these keywords being treated similar to a separate script.(but actually a child process of the main script, so only the Original Exe shows up in Task Manager))
Then its just a matter of communication between scripts.

Yes this is possible now, by compiling and FileInstalling each "thread" then running them, but this method would simplify that process, keep the compiled executable small, and put all the source code in one file(for readability).--and wouldn't break existing scripts(providing it's possible to properly implement this)

probably the sanest tradeoff to get the end result without restructuring AutoIt's source Code.

Edited by quaizywabbit, 05 July 2005 - 11:12 PM.

[blindwig]

You have command line parimeters and restart the script the in a different mode like this little script i made today.
This is good becuase you don't have to have multi exes which makes the distribution size smaller.
http://www.autoitscript.com/forum/index.php?showtopic=13190

<{POST_SNAPBACK}>

I like that idea. I haven't tried your program, but I think I know what you mean. If I have a need to do multiple tasks, I think I'll use that approach, unless something better comes up (as far as built-in features for AutoIt)

[w0uter]

maby a command like Thread($function)

here is some ugly ascii to visualise my idee.

|
   |
main flow
   |
   |
  \|/
Thread("ex") ----> function ex()
   |                   |
   |                   |
some commands   more commands
   |                   |
   |                   |
  \|/                \|/
  END                END

Edited by w0uter, 05 July 2005 - 03:08 PM.

[VicTT]

w0uter..That would be a great idea..the best I've seen till now..hmm..and I've thought this multi-threading concept since Excalibur first brought it up..This is actually do-able..Will the Dev's actually do it?Great "work", man ..GREAT work..

[Valik]

w0uter..That would be a great idea..the best I've seen till now..hmm..and I've thought this multi-threading concept since Excalibur first brought it up..This is actually do-able..Will the Dev's actually do it?Great "work", man ..GREAT work..

<{POST_SNAPBACK}>

If its so doable, when can I expect to see your implementation of it?

[MSLx Fanboy]

...With that setup w0uter, you might as well just compile a separate exe file and use the nifty ole' Run()

[VicTT]

Hmm..my implementation?Simply FileInstall("Aut2exe.exe") then make a temp exe from the func..run it without a tray icon..but that's lame and slow..BTW..when can I see anything better than useless comments..like YOUR hardcoded implementation..

[Valik]

Hmm..my implementation?Simply FileInstall("Aut2exe.exe") then make a temp exe from the func..run it without a tray icon..but that's lame and slow..BTW..when can I see anything better than useless comments..like YOUR hardcoded implementation..

<{POST_SNAPBACK}>

Did you actually read my comments and the comments of David (Nutster)? Both of us are quite familiar with the internal implementation of AutoIt. Both of us separately came to the conclusion that AutoIt would virtually need re-written to properly implement multi-threading. It is not "do-able" without writing a hack-job attempt or modifying every critical piece of AutoIt's implementation that has proven stable enough and doesn't need touched. It irks me just a bit that David and I both stated this and then people come along and ignore what we say and continue on their merry way saying "do it do it" when they have no real clue what it takes to do it and those who do have a clue have said why they won't do it.

[Fur]

I've converted a single threaded C++ application into a multi-threaded one before. Trust me, it's about the most brutal coding job you can possibly imagine, frought with the most obscure, impossible to reproduce bugs you can dream of. Keeping it fully thread-safe over the maintenance lifetime is another big problem.

A lot of us would love to see a fully threaded AutoIt, but it's not gonna happen. Even professional programmers can have a hard time writing/debugging multi-threaded code. I can't imagine turning such functionality over to the average user of AutoIt, especially without a debugger.

Hypothetically, yes it could be done. You *might* even be able to put in a very high level mutex in the interpreter and take a huge performance hit, but odds are even then, you would just be better off writing multiple scripts and executing them simultaneously.

Finally, I would suggest you check out AdLibEnable() I've found that most things I wanted to handle in a multi-threaded fashion, I can tinker something together using this function.

[VicTT]

Ok..all of us have agreed this is not easy..But just saying this over and over again will lead nowhere..The AutoIt core will (hopefully?) get complicated enough as to hinder such a big step in the future..Would you rather trace through 5000 lines of code to find&change whatever needs changing or would you enjoy 50000 better?I am exaggerating of course but someone has to start doing it..and the approach that w0uter suggested seems do-able because, in a 'hackish' way, it CAN be done(Just putting the Func in another script and executing it..This could be done automatically, by treating the said function as a separate script, and executing it alongside the main script)..I was suggesting you implement the Thread($func) so that you have a starting point for when you'll have to properly write the threading code..

[Wus]

Im not privy to anything , but after actually reading this thread Im gonna say that autoIT will not have a "thread()" function in the forseeable future... It seems like a few of the devs have made this abundantly clear.

[Valik]

VicTT, rewriting AutoIt now does the following:

• Stops all current development except for this feature because this feature will impact everything.
• Throws away 2+ years of tested and stable code in favor of exponentially more complex and untested code.
• Redefines how the language works on every level.

And just for reference, the last time I checked many months ago, I think that AutoIt was over 30,000 lines of code. I don't have a clue what it is now but I'd say its probably 5,000+ longer than it was then.

The best way to implement this is to start with 0 lines of code and go for there. The current architecture does not lend itself to multi-threading. It would be easier to start with a blank file and go from there than it would start from the existing code base. Trying to fit multi-threading into the current architecture or modify the architecture to support multi-threading leads to several significant and insurmountable flaws. This includes limiting the API so that it can work with as much current code as possible. This will cause the threading supporting not to live up to its potential. It will also force modifications to the existing code, anyway, breaking their stability. A proper design from scratch and then re-writing everything, maybe using the existing code as reference-only, is the only way to implement this.

Also, 95% of the time, multi-threading is not necessary. In general, multi-threading is a sign of poor or lazy design as opposed to clever programming. Multi-threading is never necessary; however, it can be convenient at times with regards to code organization. All multi-threaded applications have a single-threaded equivalent. That single-threaded equivalent will be terribly complex and hard to maintain, but it can be done.

So in summation, AutoIt 3 will probably not see multi-threading in its lifetime (or current iteration) because:

• Most programs do not need multi-threading, they just need better designs.
• Multi-threading can not be implemented properly in the current version of AutoIt without throwing away years worth of work.

I strongly dissuade any wide-eyed developer (current or future) who thinks they can hack this in. There can be no performance penalty. This is a high-level language and already incurs enough penalties from that aspect alone. The performance hit for executing code should be roughly equivalent to that of which it is in C++. That is, if multi-threaded C++ applications are 1% slower to execute than single-threaded, a multi-threaded AutoIt should be no more than 1% slower than the single-threaded form.