RegisterSyncCallback for v2

Discuss the future of the AutoHotkey language
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

RegisterSyncCallback for v2

Post by just me » 28 Dec 2021, 07:17

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?

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: RegisterSyncCallback for v2

Post by lexikos » 18 Jun 2022, 19:15

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:
  • 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.
I also intend to (eventually) improve support for native functions, structs, interfaces and callbacks, such as with an API for composing functions/classes that call native code or can be called by native code. For callbacks, the difference would be that you would provide the parameter types, and your function object would be called with the parameters already converted to script-readable form.

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.

crocodile
Posts: 98
Joined: 28 Dec 2020, 13:41

Re: Typed properties - experimental build available

Post by crocodile » 28 Jul 2023, 22:44

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?

lexikos
Posts: 9560
Joined: 30 Sep 2013, 04:07
Contact:

Re: RegisterSyncCallback for v2

Post by lexikos » 29 Jul 2023, 06:40

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

Post Reply

Return to “AutoHotkey Development”