RegisterSyncCallback for v2
RegisterSyncCallback for v2
I just found a script which uses RegisterSyncCallback (for multi-threaded APIs). Is this behaviour already integrated in v2 or is there a chance it will be?
Re: RegisterSyncCallback for v2
There is a chance.
Currently the main mechanism for thread synchronization is the window message loop, which is also used to queue new threads. At some point I intend to reduce AutoHotkey's dependence on the message loop by implementing an explicit queue of pending callbacks. This could have a number of uses/benefits:
RegisterSyncCallback itself isn't very interesting or as generally useful, and probably isn't too difficult to port to v2, so I'm not very likely to work on it before these other things.
Currently the main mechanism for thread synchronization is the window message loop, which is also used to queue new threads. At some point I intend to reduce AutoHotkey's dependence on the message loop by implementing an explicit queue of pending callbacks. This could have a number of uses/benefits:
- Remove limitations on the size of parameter data that can be included in new events.
- Give more control over how queued threads are executed.
- Reduce the risk of deadlock or lost events due to an external message pump dispatching messages that AutoHotkey tries to keep in the queue.
- Facilitate support for asynchronous functions and C callbacks.
RegisterSyncCallback itself isn't very interesting or as generally useful, and probably isn't too difficult to port to v2, so I'm not very likely to work on it before these other things.
Re: Typed properties - experimental build available
I remember you said in one of your posts that AutoHotkey callbacks are not safe, so you wrote RegisterSyncCallback().
Is it possible to apply the menu improvements (using separate threads) to callbacks?
Is it possible to apply the menu improvements (using separate threads) to callbacks?
Re: RegisterSyncCallback for v2
@crocodile
I moved your post to a more relevant topic, since this has nothing to do with typed properties or the experimental build.
Modeless menus allow new script threads (a.k.a. quasi-threads, pseudo-threads) to run without freezing the menu, because the menu gets input from dispatched window messages, like a GUI, instead of by polling (repeatedly calling GetMessage to "intercept" keyboard messages). It has nothing to do with real/OS-level threads which are the cause of the problems RegisterSyncCallback was designed to solve.
The limitation is not with callbacks, but with AutoHotkey itself being unable to execute script code safely on any thread that isn't the program's main thread. RegisterSyncCallback works around this by sending a message to the main thread so that it will execute the script function. It would not matter how many threads we create, whether it's for showing modal menus, performing file operations, hooking the keyboard, or whatever; the callback won't be called on one of those threads, and if it was, it's still the wrong thread for executing script code.
Now that I have put a little thought into what built-in support would actually look like, I wonder if there even needs to be an option or function for it. Script code cannot execute safely on any thread but the main thread, and checking which thread the callback is executing probably wouldn't affect performance, so perhaps it can just automatically synchronize with the main thread.
RegisterSyncCallback passes the function object and parameters in a window message, and blindly executes any function that it receives in a message. This is not ideal. If AutoHotkey had an internal mechanism for queueing threads, as I described above, it could be trivial to implement securely. Given that I already plan to work on the queueing mechanism, I intend to do that first, as I said.
I moved your post to a more relevant topic, since this has nothing to do with typed properties or the experimental build.
Modeless menus allow new script threads (a.k.a. quasi-threads, pseudo-threads) to run without freezing the menu, because the menu gets input from dispatched window messages, like a GUI, instead of by polling (repeatedly calling GetMessage to "intercept" keyboard messages). It has nothing to do with real/OS-level threads which are the cause of the problems RegisterSyncCallback was designed to solve.
The limitation is not with callbacks, but with AutoHotkey itself being unable to execute script code safely on any thread that isn't the program's main thread. RegisterSyncCallback works around this by sending a message to the main thread so that it will execute the script function. It would not matter how many threads we create, whether it's for showing modal menus, performing file operations, hooking the keyboard, or whatever; the callback won't be called on one of those threads, and if it was, it's still the wrong thread for executing script code.
Now that I have put a little thought into what built-in support would actually look like, I wonder if there even needs to be an option or function for it. Script code cannot execute safely on any thread but the main thread, and checking which thread the callback is executing probably wouldn't affect performance, so perhaps it can just automatically synchronize with the main thread.
RegisterSyncCallback passes the function object and parameters in a window message, and blindly executes any function that it receives in a message. This is not ideal. If AutoHotkey had an internal mechanism for queueing threads, as I described above, it could be trivial to implement securely. Given that I already plan to work on the queueing mechanism, I intend to do that first, as I said.