AutoHotkey Community

I need multithreading. I have tried a lot and found a lot of workarounds, though according to Chris, threading is not on the roadmap for Autohotkey. Just because Autohotkey does not support threading, does not mean that it is not a great language. I am therefore thinking whether it would be possible to use Autohotkey as a library and use a language that supports threading, like Python, to do the flow control etc. Of course, this is already possible by using Python to call Autohotkey.exe with a script file, though this is really not elegant and would kill performance totally if one merely needs Autohotkey to run a single line of code. It would also look really ugly if one had ten Autohotkey.exe processes running in the task manager, one for each thread.

The idea is therefore to compile Autohotkey into a DLL, which could simply be called from another language. I am no C++ expert, but I imagine that this would be possible. The dll would have a single function, which would take a string as input and a string as output. The input string is of course the Autohotkey script to be run and the string output would be the result.

With the proper Python wrapping, a Python script could look like the following:



I could be wrong about some things in this python script, but you get the idea.

The most important thing about this is that the HUGE Python community would get access to the functions of Autohotkey, which basically means that more people would use Autohotkey as their main language or in an embedded version. Python is a language, which works on both Windows, Linux and Unix. This means that some things that are Windows-specific are really hard to do in Python, though very easy in Autohotkey.

It would also give Autohotkey users access to Python features like utilizing Multiple processors (http://docs.python.org/library/multipro ... processing).

What do you think?

AutoHotkey Library / API posted by Auto-Mate
AutoHotkey DLL posted by sl_alagappan
AutoHotkey.exe > AHK.dll posted by Titan
DLL version of AutoHotkey posted by sl_alagappan

And these are just some of the ones from the wish list forum...

_________________
Unless otherwise stated, all code is untested

(\__/) This is Bunny.
(='.'=) Cut, copy, and paste bunny onto your sig.
(")_(") Help Bunny gain World Domination.

FYI, this would not solve the problem, as it would still be a script interpreter, and would still be unable to run scripts on multiple threads. The actual functions which are associated with each command would need to be exposed directly. Even then, each function would need to be reviewed to ensure they are thread-safe.

Thank you for the links Slanter! I am not sure you are right Lexios. I have created the following working example using Python 2.6. You also need to have AutoItX and Pywin32 installed for it to work.


This produces the following output:


This is an example where the methods are exposed directly. In this case it is the Sleep function (same as in Autohotkey). This method is surely thread-safe The reason why I am not so sure, Lexikos is that using this new type of multithreading (as if Python 2.6) two instances of Python.exe show up in the Task Manager as long as the script is running. This means that the multitheading is achieved in a very ugly way. A way that would also have been possible with Autohotkey. I believe each of these threads could have used a separate interpreter. The good thing about the multi-threading in Python is that it has a Queue class, which enables thread-safe communication between threads.

Although technically each process has its own (main) thread, there are some important differences:

• Context-switching between processes is more expensive than between threads, as threads within a process share the same address space.
• Some resources (most Win32 handles, etc.) of one "thread" would not be directly accessible by another "thread".

A "solution" that introduces more problems or limitations is not a solution. What's more, part of the reason a DLL is wanted is to allow the language itself to be replaced. Exposing the functions directly would be much easier than making the interpreter thread-safe or capable of running multiple scripts (even on a single thread; for instance, to allow A.exe, B.dll and C.dll all to run their own script).
Surprisingly, no. In most instances, Sleep and other commands which wait call the internal ::MsgSleep(), which - among other things - calls GetMessage(). If the thread never receives a message, it stalls.

Since "Sleep" is implemented directly in Line::Perform() and not as its own function, I'm not sure how it could be "exposed directly". If you simply call the Win32 function Sleep()... that's thread-safe, but it's not the same thing. "Sleep" in AutoHotkey allows window messages to be received and processed, enabling new quasi-threads to be launched. It is like an alertable wait.

Autohotkey.dll
http://www.autohotkey.com/forum/viewtopic.php?t=43049

_________________
AHK FAQ
TF : Text files & strings lib, TF Forum