AutoHotkey Community

It is currently May 26th, 2012, 3:54 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Autohotkey as DLL
PostPosted: March 12th, 2009, 3:44 pm 
Offline

Joined: July 15th, 2005, 3:19 pm
Posts: 140
Location: Denmark
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/multipro ... processing).

What do you think?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 12th, 2009, 9:12 pm 
Offline

Joined: May 28th, 2008, 2:11 am
Posts: 739
Location: Minnesota, USA

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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject: Re: Autohotkey as DLL
PostPosted: March 14th, 2009, 4:12 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject: Re: Autohotkey as DLL
PostPosted: March 14th, 2009, 5:22 pm 
Offline

Joined: July 15th, 2005, 3:19 pm
Posts: 140
Location: Denmark
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: March 15th, 2009, 4:24 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: April 9th, 2009, 8:44 pm 
Offline

Joined: May 27th, 2007, 9:41 am
Posts: 4999
Autohotkey.dll
http://www.autohotkey.com/forum/viewtopic.php?t=43049

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


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group