Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

what's IMPOSSIBLE with AHK?


  • Please log in to reply
43 replies to this topic
interiot
  • Members
  • 74 posts
  • Last active: May 31 2014 07:15 PM
  • Joined: 06 Nov 2005

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:

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...

tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
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.

Oberon
  • Members
  • 442 posts
  • Last active: Jul 03 2008 11:34 PM
  • Joined: 18 Feb 2008
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.

tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
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!

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
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).

You can make your application multithreadded with DllCalls.

Not if you want a stable application. :twisted: 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.

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 :p - multi-threading would allow us to more easily and effectively automate many things at once... or something like that. :lol:

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, :lol: safely executing multiple "threads" of script simultaneously in a single process is impossible. Multi-threading is not.

Oberon
  • Members
  • 442 posts
  • Last active: Jul 03 2008 11:34 PM
  • Joined: 18 Feb 2008

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.

m^2
  • Members
  • 100 posts
  • Last active: Mar 01 2011 09:31 AM
  • Joined: 28 Feb 2008
I wouldn't call FF fast...And being single threaded is it's drawback. How many times it hung for up to 1 second... :roll:
Very irritating especially when you're listening to music on youtube.

Anyone who trades liberty for security deserves neither liberty nor security.


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Have you used threading in .NET? It's ... not as easy as you'd hope either;

Speak for yourself...

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...

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...)

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?

Oberon
  • Members
  • 442 posts
  • Last active: Jul 03 2008 11:34 PM
  • Joined: 18 Feb 2008
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.

tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
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.

m^2
  • Members
  • 100 posts
  • Last active: Mar 01 2011 09:31 AM
  • Joined: 28 Feb 2008
You can simulate it with using multiple processes instead of threads.

Anyone who trades liberty for security deserves neither liberty nor security.


tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007

You can simulate it with using multiple processes instead of threads.


?

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

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:

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).



tic
  • Members
  • 1934 posts
  • Last active: May 30 2018 08:13 PM
  • Joined: 22 Apr 2007
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.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

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.