MultiThreaded AutoIt

[themax90]

I personal messaged Jon on this thought but would like feedback as he has not messaged me back. Will developers create a multithreaded capable AutoIt. Functions could be:

CreateThread(params)

DeleteThread(params)

I know it's possible and I hear you may have to rewrite most of the main engine, but it is worth it. Here is a sample multithread in C++

expandcollapse popup

#include <windows.h> 

// Declare headers.
long WINAPI Thread1(long lParam);


int main(void)
{
  // Declare variables and create the thread/s.
  HANDLE hThread[1];
  DWORD dwID[1];
  DWORD dwRetVal = 0;
  hThread[0] = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)Thread1,NULL,0,&dwID[0]);
  
  // Run Main Thread.
  MessageBox(NULL,"This Messagebox is from Main Thread.","Messagebox", NULL);  

  //Wait until all threads are completed before continuing.
  dwRetVal = WaitForMultipleObjects(1, hThread, TRUE, INFINITE);
  
  //Display a MsgBox to show all threads are completed.
  MessageBox(NULL,"This Messagebox is to show that all threads have completed.","Messagebox", NULL);  

  
  // Close handles.
  CloseHandle(hThread[0]);


  //End to Main Thread.
  return 0;
}

long WINAPI Thread1(long lParam)
{
  // Run Thread 1.
  MessageBox(NULL,"This Messagebox is from Thread 1.","Messagebox", NULL);
  return 0;
}

Just for other users to see how valuable threading can be(if used correctly).

Here is a zip of it(with compiled exe) :

I hope, and beg developers to thread AutoIt. It would mean the world to me and many other users out there.

Please post your thoughts on this.

Thank you,

AutoIt Smith

Edited August 8, 2006 by AutoIt Smith

[SmOke_N]

Thought: Yes, I'd love it!

Reality: Probably not going to happen any time soon.

After Thought: I'm ducking!!

[Jon]

OMG not again. Are you trying to get us all killed by a developer mob??

Thanks for the sample. It may be hard to believe but we actually do know how to do multithreading. Threads are already used in functions like MsgBox (for the timeout) and InetGet (background downloading) and a few other places. Knowing how to use CreateThread() is not the issue - that's the easy part.

I actually spent a little time driving to work this week just thinking about how to do this in AutoIt, and it's a scary scary thought and there a number of issues that are likely to be impossible to solve without starting from scratch.

The other devs have taken a look at the code with multithreading in mind and have said it's nothing short of a nightmare to convert. I've not looked properly yet and even then off the top of my head the problems are:

- I made some very bad design decisions with "Opt" and "GuiSwitch". If mutliple threads are spamming these functions what state will they be in? Should these values be "global" to all threads, or should each thread maintain it's own version of them. The first is easier to implement from my point of view but the user would be repsponsible for using semaphores in their code whenever they do something thread-unsafe (like using Opt). I don't even want to think about the kind of havoc that adlib could bring to the party. Even innocent features like WinWait commands and the last active window/handle become problematic.

- The variable table would have to lock itself whenever a thread accesses a variable. I think instead of using a full-blown windows semaphore I could just test a global boolean variable to see if the table was in use (AFAIK accessing a _single_ base-type variable in C++ with multihreading is threadsafe and doesn't need all the windows semaphore junk). I think performance would be OK with that. But if we had to add windows semaphores then I suspect performance when accessing variables would be crippled.

- Lots of functions (maybe even most) are not thread safe. There are 300+ functions and each one would have to be examined to see if they access any global data during their execution or if they are even in state that another thread could break. Even trivial stuff like "FileOpen" would need a rewrite because it checks a global filetable. Some other features like the GUI and MsgBox which are already threaded would be mindboggling to debug.

The decision to support multithreading really is a ground-up one. I may look more closely at it for my own personal amusement but if the above are the things I've come up with without even thinking about it I'd bet money that the things I've not considered would be disastrous.

[/dev/null]

I know it's possible and I hear you may have to rewrite most of the main engine, but it is worth it. Here is a sample multithread in C++

I hope, and beg developers to thread AutoIt. It would mean the world to me and many other users out there.

Please post your thoughts on this.

AutoIt Smith,

you've added a good sample of Threads in C++. So, why don't you take that sample and build multithreading into AutoIT 3.1.? The source code is available and you can do whatever you want with that. If your project is a success, I'm sure the devs will seriously consider to adapt your code changes to the current beta source, especially after you have solved some of the problems Jon mentioned.

Cheers

Kurt

Edited August 8, 2006 by /dev/null

[Valik]

Thanks for the sample. It may be hard to believe but we actually do know how to do multithreading. Threads are already used in functions like MsgBox (for the timeout) and InetGet (background downloading) and a few other places. Knowing how to use CreateThread() is not the issue - that's the easy part.

I'm glad somebody besides me stated this.

By the way, that example is not applicable to us anyway. We use parts of the C Runtime in AutoIt so we can't call CreateThread() directly. We would have to use _beginthred(ex) so that the CRT is initialized properly for those threads. So your trivial example which all of us can write in our sleep isn't even relevant to how we would have to create a thread.

Jon is right, there's pretty much nothing in AutoIt that is safe for re-entrance. The gamut ranges from poor design decisions to intentional design decisions knowing that AutoIt was not going to be multi-threaded.

Jon, I believe you are correct about the behavior of booleans with regards to threading. I think I've read in multiple places that they are atomic so it's safe to use them in the manner you describe but it seems to me like there is a reason we shouldn't use them in that way. However it's been a long time since I read anything on threading so the exact reason escapes me at the moment.

Quite simply, we'd be better off scrapping what we have now and starting over. Most of us has several years experience working on AutoIt. If we could start over, we could make significantly better design decisions and implement things in more robust, easier-to-work-on methods. Trying to port the existing code base over is detrimental for two reasons. First, it will introduce regression hell since virtually every piece of code will need changed to become thread-safe. Second, we'll essentially be rewriting AutoIt but we won't be doing it from scratch so we won't get any of the maintenance benefits or other benefits from coming up with a better initial design. So the end result is we start making tremendously buggy, unstable builds that are hard to work on for 10 months or more until we finally get most of the bugs worked out. Then we're just left with a bigger mess than what's there now so working on AutoIt becomes even harder.

[Jon]

I think after the release I'll rip all the functions out and create a personal amusement version just to see what's involved and just to see how bad the decisions we made are

I think what would be useful anyway is to check the general organisation of the code in terms of what is global, what is stored in the Script() class, what is stored in the ScriptFile() call and where the lexing is done (I was toying with the idea of moving the lexer into ScriptFile() anyway in readyness for aut2exe producing undecompilable token streams). What we do have in our favour though is the way that most functions are modular.

But this talk is very much just for my own curiosity and isn't on any roadmap.

[Valik]

Good luck with that. I think things are far too integrated at this point. Envisioning the internal relationship of various "components" is much like envisioning a web with numerous criss-crossing paths.

[Jon]

Good luck with that. I think things are far too integrated at this point. Envisioning the internal relationship of various "components" is much like envisioning a web with numerous criss-crossing paths.

I think you mentioned something ages ago that is spot on. Considering how we stumbled along and none of us are language writers or pro programmers, much of how AutoIt works is pretty well done - despite some rookie error design decisions (usually mine )

[Valik]

What the code does is done well. It's when we want the code to do something else that we run into problems. There are too many unenforced invariants, too many undocumented assumptions, too much subtle interaction. My biggest criticism is there is too much narrow minded code. There's code that could have been implemented in a generic, re-usable manner which wasn't. This seems to result in multiple similar-but-different blocks of code. For example, how many times are linked lists used?

I have a list of things I'd like to rewrite if I ever have time. Virtually none of those changes would even be user visible, either, unless they resulted in unplanned performance gains. We could probably spend the next year working on AutoIt and not add a single new feature - just fixing all our previous mistakes and making it easy to work on AutoIt.

[JSThePatriot]

Due to my _ComputerGet*Info* UDF's I have noticed that AutoIt is already multi-threaded in a few parts.

I would never pretend to know enough C/C++ to help with this, but if the benefit is great enough would it be worth considering rebuilding AutoIt for a v4 that would include Multi-Threading? If I knew enough C/C++ I would offer to start a "from scratch" concept design, but I dont think I am to that point yet.

I would love to see AutoIt be able to multi-thread to be able to accomplish more at the same time. I do however understand that isnt where AutoIt is/was headed, but looking forward does make it look like it would be a good direction to go.

Thanks,

JS

[/dev/null]

I would never pretend to know enough C/C++ to help with this, but if the benefit is great enough would it be worth considering rebuilding AutoIt for a v4 that would include Multi-Threading? If I knew enough C/C++ I would offer to start a "from scratch" concept design, but I dont think I am to that point yet.

I would love to see AutoIt be able to multi-thread to be able to accomplish more at the same time. I do however understand that isnt where AutoIt is/was headed, but looking forward does make it look like it would be a good direction to go.

I can't believe you wrote this after all the other posts ...

Valik, it's your turn Be kind ....

Cheers

Kurt

[Valik]

What parts do you think AutoIt is multi-threaded in? Unless you're using the timeout feature of MsgBox() or InetGet(), AutoIt itself doesn't use any threads outside of the main thread.

[themax90]

How about you make some "Rough Code" and tamper with it in the next few beta releases that does this.

CreateThread("Thread1")
While 1
     ;Main Thread
WEnd
Func Thread1()
     ;Thread 1
EndFunc

Rough translation into making a thread with all the lines of Thread1.

Is this even possible to try or are most things just no thread safe. I cannot do much more networking or TCP/IP without the multithread option and all I would be doing is using TCPRecv and writing 2 variables. The other thread would be a bunch of Select...Case's going off into other functions in the main thread in case of a determined string.

Is making rough code possible, or just to far away?

(I enjoy all you talking because it explains alot that I havn't been able to understand about the AutoIt core.)

AutoIt Smith

[SmOke_N]

Quite simply, we'd be better off scrapping what we have now and starting over. Most of us has several years experience working on AutoIt. If we could start over, we could make significantly better design decisions and implement things in more robust, easier-to-work-on methods.

If that ever became a reality, I'd like to be a guinea pig for that!!

[themax90]

I would test it non-stop for you guys. If you could even implement a beta version of threading. Just for people to play with. I would be elated.

Still don't know if rough threading is even close to possible, even to play around with.

[JSThePatriot]

I can't believe you wrote this after all the other posts ...

Valik, it's your turn Be kind ....

Cheers

Kurt

What's that supposed to mean? Am I normally not nice? If that is the case, I wasnt trying to be nice, but I try to side with the developers. Though I am more of a web developer, I do understand the development process for applications. I am trying to get more into other developments other than on the web.

What parts do you think AutoIt is multi-threaded in? Unless you're using the timeout feature of MsgBox() or InetGet(), AutoIt itself doesn't use any threads outside of the main thread.

I use the timeout feature on MsgBox() all the time, but I was curious about the multi-threaded parts of AutoIt like I said due to my new UDF's I have been playing with. One of them showed that the AutoIt3.exe has roughly 4 threads no matter what script I run. Now... I could have mis-read that info, as I am not claiming I am perfect, but it lead me to believe there are parts of AutoIt that are multi-threaded not to mention the fact that I knew from before that InetGet() did download in the background.

As stated above I understand both sides of the table. There are needs that would be more easily completed using threads, but at the same time to getting AutoIt to that point is a massive undertaking. I have also stated that I am unable to do this so my voice in the matter isnt very significant, and I understand that.

Thanks,

JS

[jftuga]

While we are dreaming (ie threads), what I would rather see in a next generation AutoIt is the ability to compile to exe "only what you need", not the entire interpreter. This would exclude eval, execute, assign, call, etc., etc.

I am not sure how this would be done. Maybe you would distribute object files (or library) that would have an intelligent front-end that linked in only the needed functionality. Or is this an even crazier idea than threads?

The advantages that I see are a smaller executable size and smaller memory foot print. It *might* run the code faster. One disadvantage is that I don't know how or even if you could distribute a linker. Maybe end users would have to download the free version of MS Studio Express.

-John

Edited August 8, 2006 by jftuga

[JSThePatriot]

While we are dreaming (ie threads), what I would rather see in a next generation AutoIt is the ability to compile to exe "only what you need", not the entire interpreter. This would exclude eval, execute, assign, call, etc., etc.

I am not sure how this would be done. Maybe you would distribute object files (or library) that would have an intelligent front-end that linked in only the needed functionality. Or is this an even crazier idea than threads?

The advantages that I see are a smaller executable size and smaller memory foot print. It *might* run the code faster. One disadvantage is that I don't know how or even if you could distribute a linker. Maybe end users would have to download the free version of MS Studio Express.

-John

Have you seen this solution? CleanScript

That should help atleast get you started in the proper direction.

JS

[Valik]

AutoItSmith, I really shouldn't answer your question because it's quite idiotic since Jon and I have both stated that AutoIt is not thread safe. Making it thread safe is not easy. It's not simple. It requires reading at least 95% of the code in AutoIt. Who knows how much of that code would need touched to be made re-entrant safe. I don't know how big AutoIt is specifically but I do know it's a few ten-thousand lines of code.

Can I implement your script to make it work? Absolutely, in probably 20 minutes. The moment you try to do anything more than what your script does, AutoIt will crash.

Before you ask another stupid question, please read the thread and take time to reflect on what has been said. Jon and I should have made it very clear that this is not something that is going to happen in the near future (Within at least the next year or more). If it was not clear, then it was not clear specifically to you and you should spend further time absorbing what is being said.

JS, Any DLL loaded into the address space of AutoIt can create a thread and that thread will be part of AutoIt. That doesn't mean we created it. For example, I wouldn't be at all surprised if WMI stuff created threads. As far as I know, at most, AutoIt can only have up to three threads running that we created: The main thread, the MsgBox() timeout thread and the InetGet() thread. Those are the only three I can think of. Any others were probably created by a DLL that was loaded into AutoIt's address space.

jftuga, this isn't a "dreaming" thread, this is a thread about a specific concept. Please take other ideas elsewhere.

[jftuga]

jftuga, this isn't a "dreaming" thread, this is a thread about a specific concept. Please take other ideas elsewhere.

I apologize. I didn't mean to "hijack" the thread. It would have been more appropriate for the Idea Lab.

-John