| View previous topic :: View next topic |
| Author |
Message |
interiot
Joined: 06 Nov 2005
Posts: 50
|
 Posted: Mon Mar 31, 2008 3:59 pm Post subject: |
 |
|
| tic wrote: | | multithreading! |
AHK handles basic mulithreading for you pretty well, actually. New users probably have no idea they're writing multithreading code. There's ways to have explicit control over it too:
| Code: | SetTimer, thread2, -1 ; create a new thread
thread2:
Sleep, -1 ; yield
Exit ; kill this thread
|
Or were you referring to the restriction that two threads can't actually be running at the exact same time (on dual cores)? Due to synchronization issues, mainline Python doesn't even have that... |
|
| Back to top |
|
 |
tic
Joined: 22 Apr 2007
Posts: 1271
|
| Posted: Mon Mar 31, 2008 4:07 pm Post subject: |
|
|
| No I'm not talking about separate subroutines. For example I wish to be able to simulataneously download several files at once, but you cannot break from a function once it has been entered to simultaneously run another. |
|
| Back to top |
|
|
Oberon
Joined: 18 Feb 2008
Posts: 408
|
| Posted: Mon Mar 31, 2008 4:15 pm Post subject: |
|
|
You can make your application multithreadded with DllCalls. I think having it as built-in functionality is beyond the scope of a hotkey driven scripting language.
_________________
 |
|
| Back to top |
|
|
tic
Joined: 22 Apr 2007
Posts: 1271
|
| Posted: Mon Mar 31, 2008 5:08 pm Post subject: |
|
|
| No I've spoken at length about the create thread function in old posts. It is unreliable and immediately crashes on most of the computers I have tried it on. It is not beyond the scope of a hotkey driven scripting language. AutoIt is partially there by allowing the download to run in the background using InetGet. Even that would be a big improvement! |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2359
Location: Australia, Qld
|
| Posted: Tue Apr 01, 2008 8:13 am Post subject: |
|
|
Sean demonstrated in the UrlDownloadToVar thread how to perform an asynchronous download. FileExtract_ToMem demonstrates how machine code may be used for multi-threading. Other functions may be performed asynchronously from AutoHotkey; for instance, overlapped I/O (file, comms, network, etc. input and output).
| Oberon wrote: | | You can make your application multithreadded with DllCalls. |
Not if you want a stable application.  AutoHotkey is not designed to be multi-threaded. Even executing a single line of script is not thread-safe, since static member variables are used to store the intermediate value of each arg.
| Oberon wrote: | | I think having it as built-in functionality is beyond the scope of a hotkey driven scripting language. |
Automation precedes Hotkeys in the AutoHotkey motto  - multi-threading would allow us to more easily and effectively automate many things at once... or something like that. 
Unfortunately and for the same reasons it cannot be done safely with DllCall, adding multi-threading support to AutoHotkey scripts would be far from simple.
To get back on topic, safely executing multiple "threads" of script simultaneously in a single process is impossible. Multi-threading is not. |
|
| Back to top |
|
|
Oberon
Joined: 18 Feb 2008
Posts: 408
|
| Posted: Tue Apr 01, 2008 10:20 am Post subject: |
|
|
| Lexikos wrote: | | multi-threading would allow us to more easily and effectively automate many things at once |
I actually support the idea to disagree. PHP, JS, Python (kinda) and even Firefox are some examples of single-threaded languages and applications that prove to be reliable and fast. I don't want my ordinary scripts to be 10x slower and buggy on non-standard processors just because the engine has become thread safe. Have you used threading in .NET? It's not difficult but not as easy as you'd hope either; it's certain that a feature like this in AutoHotkey would be tremendously underutilized, so from a developers perspective there is no sufficient demand to justify the hours of R&D. Besides we already have a highly specialized mechanism for quasi-multithreading (in Chris' own words) - refer to the SetTimer, Thread and Critical commands in the help file, what you ask for is readily achievable... you just need to be creative.
_________________
|
|
| Back to top |
|
|
m^2
Joined: 28 Feb 2008
Posts: 34
Location: Krk, PL
|
| Posted: Tue Apr 01, 2008 12:27 pm Post subject: |
|
|
I wouldn't call FF fast...And being single threaded is it's drawback. How many times it hung for up to 1 second... 
Very irritating especially when you're listening to music on youtube.
_________________
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2359
Location: Australia, Qld
|
| Posted: Tue Apr 01, 2008 12:38 pm Post subject: |
|
|
| Oberon wrote: | | Have you used threading in .NET? It's ... not as easy as you'd hope either; |
Speak for yourself...
| Quote: | | there is no sufficient demand to justify the hours of R&D. |
That is why I mentioned that it would not be simple. I've never suggested that Chris should work on it; in fact, I don't see that happening. It is something that has been in the back of my mind for a while, and will stay there until, one way or the other, it has been implemented...
| Quote: | | what you ask for is readily achievable... you just need to be creative. |
What I meant by "more easily and effectively" was to not require "creativity." Also, there are situations where SetTimer is not practical or simply won't work. (I have already demonstrated one way around that, but it requires the use of a compiled language...)
| Quote: | | I don't want my ordinary scripts to be 10x slower and buggy on non-standard processors just because the engine has become thread safe. |
Why would you expect that to happen? |
|
| Back to top |
|
|
Oberon
Joined: 18 Feb 2008
Posts: 408
|
| Posted: Tue Apr 01, 2008 12:58 pm Post subject: |
|
|
Perhaps I worded that wrongly. Multithreadding in .NET I find is quite simple if you understand callbacks, delegates (thread safe invoke models) and don't mind the tedious job of writing a bunch of extra statements for them. If you think from the perspective of a typical non-programmer hobbyist using AutoHotkey (which is the target audience I believe) it may seem like a daunting prospect. This program is a niche tool like no other, so it gets on my nerves when people suggest things that would make it more inaccessible to newbies when they can already be simulated by various other means.
_________________
|
|
| Back to top |
|
|
tic
Joined: 22 Apr 2007
Posts: 1271
|
| Posted: Tue Apr 01, 2008 1:03 pm Post subject: |
|
|
Gets on your nerves! Sorry!
I dont need full multithreading, but it would be nice if a flag could be set for some functions to allow them to continue even if another function was launched. |
|
| Back to top |
|
|
m^2
Joined: 28 Feb 2008
Posts: 34
Location: Krk, PL
|
| Posted: Tue Apr 01, 2008 1:52 pm Post subject: |
|
|
You can simulate it with using multiple processes instead of threads.
_________________
|
|
| Back to top |
|
|
tic
Joined: 22 Apr 2007
Posts: 1271
|
| Posted: Tue Apr 01, 2008 2:44 pm Post subject: |
|
|
| m^2 wrote: | | You can simulate it with using multiple processes instead of threads. |
? |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2359
Location: Australia, Qld
|
| Posted: Wed Apr 02, 2008 3:05 am Post subject: |
|
|
| Oberon wrote: | | This program is a niche tool like no other, so it gets on my nerves when people suggest things that would make it more inaccessible to newbies when they can already be simulated by various other means. |
Relax. My previous post was intended to imply that if Chris doesn't do it, I will. What I do with my custom builds of AutoHotkey will not in any way affect users of the official build. Even so, you seem to be assuming adding these features would somehow change the behaviour of existing scripts. I have no doubt that true multi-threading could be made simpler and more effective than any current method of simulating concurrent execution.
m^2, though I agree that is an option, us multi-threading advocates would like to avoid the overhead of one or more extra processes and of inter-process communication. (I was considering mentioning earlier that since each process has at least one thread, multiple processes means multiple threads.) 
tic, how many of your applications for multi-threading would be based around DllCalls? IMO, it would be practical to build a generic AsyncDllCall(), from script even.
Btw, here is Chris' reasoning:
| Chris wrote: | AutoHotkey doesn't currently support multiple process-threads due to the need to make many sections thread-safe, which in turn would:
1) Increase code size.
2) Reduce performance in many areas due to the need to enforce thread-safety.
3) Be very costly in development time (probably 4-8 weeks of full-time work). |
|
|
| Back to top |
|
|
tic
Joined: 22 Apr 2007
Posts: 1271
|
| Posted: Wed Apr 02, 2008 4:14 pm Post subject: |
|
|
I would bow before the person that could implement it. Tbh Lex, most scripts I have given up on due to not having access to multithreading are task intensive programs that must continually be doing some function, thus making the gui unusable. It is impossible to split it into 2 exes (not that I would want to as that is extrmeley messy) because it would still be too intensive for the "gui exe" to be receiving the information back and updating the the gui.
An example that I gave up on, which I would like to still write, and I'm not sure if that COM post by Sean you pointed me to can help is a torrent searching program.
So you type a search term and it has definitions for many torrent sites on how to parse their html. It would then need to download say 5 pages at a time (and timeout if a page is not downloaded in an expected time), then parse each page using RegEx for generic torrent information (torrent name, number of files, leeches, seeds....) and then update a listview based on all this information.
This needs to have more than 1 thread operating at once as then you cant use the listview while you are searching.
I have many other projects I had wanted to do, but after a while I decided that without being able to do something else whilst a function is running the project would be too user unfriendly. So the gist of it is that my main reason for wanting "multithreading" is for gui purposes. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2359
Location: Australia, Qld
|
| Posted: Wed Apr 02, 2008 10:08 pm Post subject: |
|
|
| tic wrote: | | An example that I gave up on, which I would like to still write, and I'm not sure if that COM post by Sean you pointed me to can help is a torrent searching program. |
I don't see why not. The most time consuming part is downloading. Using the methods Sean posted you can start a download then continue processing messages until the download is complete. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
