MultiThreaded AutoIt

[Valik]

It would be more appropriate left in your head, to be honest. We've heard the idea before. We know that some people want that. It's not a new idea. Therefore, there's no point bringing it up again.

[JSThePatriot]

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.

Valik, I appreciate the response. I didnt realize that about DLLs, and I would be willing to agree that the WMI that I have been using could easily have created additional threads.

Thanks again,

JS

[Jon]

I don't know how big AutoIt is specifically but I do know it's a few ten-thousand lines of code.

It's the number of lines at the bottom if someone wants to add it up

But please, try to go easy on people. It's easy for us who are up to our neck in the nightmare that is autoit source code to see how hard it is - I imagine it's quite hard to understand from the outside

I understand that ppl want it, and I think it's a neat idea too, but the level of difficulty given and the size of the task is greater than the time we currently have to develop. As I said, I'll give it a go as a proof of concept, but it's got "complete rewrite" all written all over it.

expandcollapse popup

202
97
230
92
205
334
3377
90
292
98
285
251
2791
94
243
221
1455
126
228
97
186
95
90
163
92
149
123
168
86
162
90
255
78
179
107
1481
125
1163
2926
417
1723
442
861
2241
2008
4192
2167
4352
981
651
1483
3352
102
1203
2352
189
1532
168
1609
930
289
94
289
121
286
192
643
78
243
105
130
115
351
485
1603
590
8659
142
128
66
84
269
73
130
138
88
67
69
92
200
148
962
120
866
93

[Wus]

68156 lines of code

[themax90]

MultiThreading is the only thing stopping this language from coming to a full-scale use(in some areas).

Hopefully your proof of concept goes well. And perhaps you may not need to rewrite as much as you think.

@Valik

It is very hard from the outside to understand the amount of rewrite possible, specifically because I DON'T know much C++. And even if there are that many lines to rewrite. Why not go through most all the functions and rewrite/edit them to be thread-safe. I'm not understanding it completely. Is the calling/function engine needing to be rewritten for this as well?

I understand a complete rewrite would take a long time. However, I do not understand the problems you would create by doing it.

[/dev/null]

68156 lines of code

no. 69489 lines.

Cheers

Kurt

[/dev/null]

MultiThreading is the only thing stopping this language from coming to a full-scale use(in some areas).

Multithreading?? Are you serious? There are a million other things. Just one to mention: Lack of complex data structures. I rather want to see something like associative arrays (like hashes in perl) or "structs" (like in C) than any multithreading stuff. How often do you need multithreading and how often do you need more complex data structures than strings and arrays???

Cheers

Kurt

Edited August 8, 2006 by /dev/null

[piccaso]

It's the number of lines at the bottom if someone wants to add it up

ConsoleWrite(202 + 97 + 230 + 92 + 205 + 334 + 3377 + 90 + 292 + 98 + 285 + 251 + 2791 + 94 + 243 + 221 _
         + 1455 + 126 + 228 + 97 + 186 + 95 + 90 + 163 + 92 + 149 + 123 + 168 + 86 + 162 + 90 + 255 + 78 + 179 _
         + 107 + 1481 + 125 + 1163 + 2926 + 417 + 1723 + 442 + 861 + 2241 + 2008 + 4192 + 2167 + 4352 _
         + 981 + 651 + 1483 + 3352 + 102 + 1203 + 2352 + 189 + 1532 + 168 + 1609 + 930 + 289 + 94 + 289 + 121 _
         + 286 + 192 + 643 + 78 + 243 + 105 + 130 + 115 + 351 + 485 + 1603 + 590 + 8659 + 142 + 128 + 66 _
         + 84 + 269 + 73 + 130 + 138 + 88 + 67 + 69 + 92 + 200 + 148 + 962 + 120 + 866 + 93)
; = 69489

i cant think of one thing why threads are absolutely necessary.

been using seperate processes ever since, and i'm happy whith it...

[Jon]

MultiThreading is the only thing stopping this language from coming to a full-scale use(in some areas).

Hopefully your proof of concept goes well. And perhaps you may not need to rewrite as much as you think.

@Valik

It is very hard from the outside to understand the amount of rewrite possible, specifically because I DON'T know much C++. And even if there are that many lines to rewrite. Why not go through most all the functions and rewrite/edit them to be thread-safe. I'm not understanding it completely. Is the calling/function engine needing to be rewritten for this as well?

I understand a complete rewrite would take a long time. However, I do not understand the problems you would create by doing it.

Well in the last year I've only had time to write like 500 lines of code. So a complete rewrite would be... ooo... 138 years Lol

[/dev/null]

ConsoleWrite(202 + 97 + 230 + 92 + 205 + 334 + 3377 + 90 + 292 + 98 + 285 + 251 + 2791 + 94 + 243 + 221 _
         + 1455 + 126 + 228 + 97 + 186 + 95 + 90 + 163 + 92 + 149 + 123 + 168 + 86 + 162 + 90 + 255 + 78 + 179 _
         + 107 + 1481 + 125 + 1163 + 2926 + 417 + 1723 + 442 + 861 + 2241 + 2008 + 4192 + 2167 + 4352 _
         + 981 + 651 + 1483 + 3352 + 102 + 1203 + 2352 + 189 + 1532 + 168 + 1609 + 930 + 289 + 94 + 289 + 121 _
         + 286 + 192 + 643 + 78 + 243 + 105 + 130 + 115 + 351 + 485 + 1603 + 590 + 8659 + 142 + 128 + 66 _
         + 84 + 269 + 73 + 130 + 138 + 88 + 67 + 69 + 92 + 200 + 148 + 962 + 120 + 866 + 93)
; = 69489

Wow, how long did it take you to write that code? With Excel it took me 20 seconds, while the loading of Excel took ~15 seconds

Cheers

Kurt

[Wus]

no. 69489 lines.

Cheers

Kurt

Whoops, good thing I am not a math major or anything.

<---- (math major)

:">

Edited August 8, 2006 by Wus

[piccaso]

Wow, how long did it take you to write that code? With Excel it took me 20 seconds, while the loading of Excel took ~15 seconds

Cheers

Kurt

i didnt write it myself.

good old (single threaded) autoit did it for me

$aNumbers = StringSplit(ClipGet(),@LF)
ConsoleWrite("ConsoleWrite(")
For $i = 1 To $aNumbers[0] - 1
    ConsoleWrite(StringStripCR($aNumbers[$i]) & "+")
Next
ConsoleWrite($aNumbers[$aNumbers[0]] & ")" & @LF)

just did some formating and tidy did the rest

[themax90]

I would use Threading very much. The thought of being able to operate a GUI and process in the background would be very awesome to me. My current project needs it. My old blackjack script(if I picked it up again) would be good because I could create/load a bank while creating and load a card deck. I can watch processes with my PListD while doing other things(thus anti-virus software). I can make greater and faster TCP and UDP servers. Games in AutoIt would be more of a good idea. For example a game in autoit could 1)Chat, 2)Receive Multi TCP, 3)Send Multi TCP, 4)Play Game, 5)Process Realtime data all at the same time. Thus being a real game/rpg. Right there are 4-5 fullscale possible projects to be written in AutoIt that cannot be done(well) w/o threading

Of course all of this only if it was used correctly. There are tons of ways multithreading can be useful. It is the biggest door opener currently. Plus the rewrite they will have to do, will allow them to add functions and structs easier.

This however is just my opinion. Jon, personally I think if you sit down for 2-3 hours per day and code you can do it really fast(Being 3-6months). Assign each developer to a specific part and then edit there code to perfection. Just an idea.

AutoIt Smith

[/dev/null]

Jon, personally I think if you sit down for 2-3 hours per day and code you can do it really fast(Being 3-6months).

How "sweet"

EDIT: I guess, when you're out of school and you're forced to earn your own money (let's say for ..... FOOD), you will probably understand how ridiculous your suggestion is...

Cheers

Kurt

Edited August 8, 2006 by /dev/null

[Valik]

Smith, please just shut up. Please? I really don't know how to get it into your head that this isn't just some trivial afternoon project. You've said numerous stupid things now. How can you not understand the scope that this is on? Can't you even imagine it just a little bit? In all your great socket-project glory, haven't you written anything even just a little complicated that you don't want to write over again from scratch? This statement right here makes me think you are a highly stupid person:

I understand a complete rewrite would take a long time. However, I do not understand the problems you would create by doing it.

How do you not understand that taking existing code and changing it will inevitably produce broken code? Have you ever written a line of code in any language in your life? Haven't you ever modified a single line of code and accidentally broken an entire program?

I'm at a complete and utter loss how you can be so absolutely oblivious to the words Jon and I have been using. Does the phrase "total rewrite" mean nothing to you? Even if you don't know C++, don't those two words have any significant meaning to you?

[themax90]

Like Valik. Don't be a fucking asshole. I completely understand it. However when you REWRITE code, it's no different then starting from the beginning. THUS you CANNOT break a PROGRAM which IS NOT WRITTEN. Follow the logic Valik. I am not oblivious to the words you have said. I understand them perfectly. HOWEVER IF YOU DID NOT LISTEN.

I do not understand how you could "BREAK" code you are writing from "SCRATCH".

I HAVE broken a program by editing a line, but I search for ALL INSTANCES of it, and fix it quickly. If you start from the beginning, of course you will need to change errors, but that doesn't mean your breaking it. All programs need to be debuged at some point, no matter how good the programmer. Debugging is IN the writing process.

There are MANY things I don't want to write from scratch, but I do. It's because I am writing from scratch that I cannot break it.

Why don't you IMAGINE that your logic is WRONG. Then visualize the reality. It is wrong. I do not want to pick a fight with you. But calling names is no way to be friendly. It was a question, not a very decisive question, but is was. If you would have answered it, then all would have been fine. However since you fail to do that, things start.

[piccaso]

THUS you CANNOT break a PROGRAM which IS NOT WRITTEN.

damn!

autoit hasnt even been written?

all my scripts are useless...

Edited August 9, 2006 by piccaso

[Valik]

Telling me not to be a "fucking asshole" is like telling water not to be wet.

We didn't write some of this code to work right the first time through, what makes you think we'll hit it dead nuts the second time, especially since we have to write it in a completely different manner? Whether we modify existing code or write the code from scratch, a multi-threaded release will not work the same as the current code base even in places where it is supposed to. There will be parts that are terribly broken. There will be parts that unintentionally behave differently. It doesn't matter if the code is all brand new or modifications on the existing code, AutoIt will be terribly broken for several months. That's on top of the year or two spent developing the feature. Adding multi-threading would require taking one step forward and 302 steps backwards. All the work we've spent the last 3+ years on would be gone. In it's place would be virgin code that would be just as buggy as when we started. Either that or the code would be whored-out code that's been so used and abused that the only reason it works is pure dumb luck.

[themax90]

Thank you for answering the question(in some sense). Valik sometimes you can't always be on the gun. I notoriously have a flared temper in some situations. But always being that way gets people no where fast.

I did not know that certain functions may act differently under threading. I don't have much C++ experience. Not everyone has the knowledge of an AutoIt Developer.

[Richard Robertson]

Oh my goodness, what a war.

I think that if AutoIt were to become a "full scale language," compiled executables would be at hand. As it is now, AutoIt is a packaged interpretter from my understanding, please correct me if I am wrong. A real exe file with actual code in it such as a C++ compiled program or any other language (not java or .Net). This would reduce the end application filesize and would solve people's suggestions of specific linkage to script used pieces.