Execution modes and lifetime
Common AHK modes
| Type | Behavior |
|---|---|
| f | Function body with this, using the default pool |
| c | Function call using the default pool |
| jf / jc | Function body / call in a Job process pool |
| ef / ec | Function body / call in an independent process pool |
| d | New default interpreter instance |
| j | New Job process with a complete script |
| e | New independent process with a complete script |
| l / jl / el | Cached label-style execution |
| t | Forward to a named receiver |
| r | Native action |
Types are lowercased and combinations generally normalized. Only defined combinations have execution branches.
Default backend
no_dll=1 routes the default AHK backend to Job processes. no_dll=2 routes it to independent processes. A function's type alone therefore does not determine whether it actually runs inside a DLL.
Reuse and debugging
An interpreter can retain compiled functions, labels, libraries and globals. Commands cannot rely on always receiving the same pool instance. read serves independent-thread debugging. Restart after changing cached function bodies or label code.
Instance limits
limit=1 skips creation when a matching instance is available. limit=2 asks the existing instance to exit, then creates another. limit=3 toggles by requesting exit when present and starting when absent. These are same-name receiver conventions.
Complete scripts use ExitApp when they should finish. ExitApp inside a pooled function terminates its interpreter. Job processes generally follow root Job cleanup, while independent processes can persist.
Other runtime types include Python jp/ep, JavaScript js/es, PowerShell jw/w and Lua ju/du, with their matching runtime and base scripts.