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