 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
 Posted: Thu Mar 12, 2009 2:44 pm Post subject: Autohotkey as DLL |
 |
|
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:
| Code: | script = """
run, notepad.exe
WinWaitActive, Untitled -
Send, This is a test
"""
from ctypes import *
AutoHotKeyDll.RunScript("c_char_p", script);
|
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/multiprocessing.html#module-multiprocessing).
What do you think? |
|
| Back to top |
|
 |
Slanter
Joined: 28 May 2008
Posts: 739
Location: Minnesota, USA
|
| Posted: Thu Mar 12, 2009 8:12 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Sat Mar 14, 2009 3:12 pm Post subject: Re: Autohotkey as DLL |
|
|
| David Andersen wrote: | | 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. |
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. |
|
| Back to top |
|
|
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
| Posted: Sat Mar 14, 2009 4:22 pm Post subject: Re: Autohotkey as DLL |
|
|
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.
| Code: | import time
from multiprocessing import Process
import win32com.client
auto=win32com.client.Dispatch('AutoItX3.Control')
def f(name):
for i in range(1, 6):
auto.Sleep(1000)
print name + str(i)
if __name__ == '__main__':
t1 = time.time()
p = Process(target=f, args=('Thread 1: ',))
p2 = Process(target=f, args=('Thread 2: ',))
p.start()
p2.start()
p.join()
p2.join()
t2 = time.time()
print "It took: " + str(t2-t1) + " seconds to count from one to five two times, with one second delay"
|
This produces the following output:
| Code: | Thread 1: 1
Thread 1: 2
Thread 1: 3
Thread 1: 4
Thread 1: 5
Thread 2: 1
Thread 2: 2
Thread 2: 3
Thread 2: 4
Thread 2: 5
It took: 5.19600009918 seconds to count from one to five two times, with one second delay
|
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. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Sun Mar 15, 2009 3:24 am Post subject: |
|
|
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).
| Quote: | | This method is surely thread-safe |
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. |
|
| Back to top |
|
|
SoLong&Thx4AllTheFish
Joined: 27 May 2007
Posts: 4999
|
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
