With Semaphores Added The AppleScript GUI Scripting Grinds To A Halt

AppleScipt user interaction and GUI control commands grind to a halt taking exorbitant time to respond (up to 5-7- sec) when KM Engine runs interface control actions continuously - with intervals between runs as short as 2 sec - with Semaphore Locks added. The only cure is to re-load the Engine. The AppleScript commands that suffer are choose from list, display dialog of Standard Additions, and set/get frontmost and click of System Events.
Such KM actions as Move and Click and Drag take a heavy toll too.

I'm seeing spikes in the numbers (the 5-digit ones) that apparently denote the time for KM Engine to return feedback.

A relevant extract from Engine.log:

2023-07-15 00:40:40 Running application query took a while (3300 us)
2023-07-15 00:40:40 Running application query took a while (3590 us)
2023-07-15 00:51:10 Running application query took a while (4211 us)
2023-07-15 02:05:43 Running application query took a while (4240 us)
2023-07-15 11:40:59 Running application query took a while (4773 us)
2023-07-15 11:40:59 Running application query took a while (3611 us)
2023-07-15 12:02:14 Running application query took a while (3982 us)
2023-07-15 12:02:45 Running application query took a while (4813 us)
2023-07-15 12:11:59 Running application query took a while (10152 us)
2023-07-15 18:20:50 Running application query took a while (3519 us)
2023-07-15 23:54:20 Running application query took a while (4432 us)
2023-07-15 23:54:20 Running application query took a while (4089 us)
2023-07-15 23:55:55 Running application query took a while (10627 us)
2023-07-16 00:55:15 Running application query took a while (3921 us)
2023-07-16 03:08:37 Running application query took a while (3283 us)
2023-07-16 19:32:06 Running application query took a while (8636 us)
2023-07-16 21:37:40 Running application query took a while (4211 us)
2023-07-17 00:46:25 Running application query took a while (5331 us)
2023-07-17 00:52:41 Running application query took a while (10145 us)
2023-07-17 02:41:09 Running application query took a while (4207 us)
2023-07-17 02:41:46 Running application query took a while (3222 us)
2023-07-17 03:01:21 Running application query took a while (3990 us)
2023-07-17 03:07:29 Running application query took a while (5003 us)
2023-07-17 03:07:40 Running application query took a while (3585 us)
2023-07-17 03:10:25 Running application query took a while (3471 us)
2023-07-17 05:23:58 Running application query took a while (14584 us)
2023-07-17 05:23:58 Running application query took a while (3731 us)

The visual representation:

macOS 10.14
KM 10.2

The log messages are irrelevant to this. They are small and infrequent.

I'm afraid I don't really have anything to suggest, I don't really understand what you mean.

The Mouse Click action is not an AppleScript action.

Semaphore Locks have obvious to do with anything (they affect the Keyboard Maestro macros that run, and how they progress, but they have no affect on AppleScript).

I don't really understand what specifically you are seeing, but I would suggest you simplify the issue to a single thing happening at a single time, when no macros are actually running, or when only one macro is actually running.

I would also suggest that Evaluate Conditions is turned off (in the View menu) to ensure the editor is not adding confusion by evaluating complex conditions to display the results.

Please, read my message carefully. If something's not clear read again until it is.

But, without risking to appear repetitive, I can only re-dress the statements as the following:

I've observed that when I prepend KM actions (the examples are below) with the semaphore locks, it negatively impacts AppleScript GUI scripting (i.e., impeding System Events) overall, KM actions such as Move-Click-Drag and AppleScript scripts dealing with user interaction from within KM as well. At this point, even disabling the semaphores doesn't lead to an immediate effect unless - with the semaphores disabled - I kill and re-launch the KM Engine. It then brings GUI round, and all user interaction recovers to its default responsiveness.

The linked video in the OP illustrates real-time AppleScript script action. The last second of the video is when the action simulating the key shortcut ⌘-F is acknowledged. The interval between and after getting and setting the frontmost property is about 5 sec, and, for key strokes, it's even longer.

An example of offending KM macros:

KM Macro

The AppleScript script in operation as captured in the linked video. Note. It was executed outside KM while KM was running the above macros in the background with the semaphores enabled.

(* Created and tested on macOS 10.14
AppleScript 2.7 *)

tell application "System Events"

if my player_cpu("iina") > 1 then -- IINA is playing the file
	
	tell application process "IINA"
		repeat until frontmost is true
			set frontmost to true
			delay 0.1
		end repeat
		repeat until exists window 1
			delay 0.1
		end repeat
		if window 1's position is not {0, 0} then keystroke "f" using command down
		
	end tell
end if
end tell


on player_cpu(_process)
return (do shell script "ps -U `id -u` -o %cpu,comm | grep -i " & _process & " | awk -F'[. ]' '{if ( $2 ) print $2\",\"$3 ; else print $3\",\"$4;}'") as number
end player_cpu

Woah there, let’s keep it friendly. :wink: The gentleman who replied to you is the developer of KM, and extremely knowledgeable and helpful. When he says he doesn’t understand something, there’s merit behind those words. FWIW, I found your initial post a little hard to follow as well, though I’m not near as talented/experienced as Peter and a lot of other folks here.

That being said, from what I’ve seen over the years with Keyboard Maestro (and AppleScript), the things you’re describing don’t appear to have a direct relation. Over the years I have found AppleScript to be finicky all on it’s own, for no apparent reason, and through no fault of Keyboard Maestro, and more so when it’s being used for GUI actions. I can’t think of any reason why a semaphore action would affect AppleScript... I don’t think those actions they way they are written even make use of AppleScript.

Just spitballing, but I’d suggest looking into the Script Debugger app for any AppleScript-related work as it is far superior to Apple’s native Script Editor app. Running your AppleScript in it might shed some more light on what’s happening.