@peternlewis - I’m trying to debug some prototype code, and I’m having issues, so I thought I’d verify some assumptions.
To be clear, I don’t think any of these assumptions are causing my issue. I’m dealing with a situation where it seems like a semaphore isn’t getting unlocked. It’s most likely due to some code of mine that is hanging somehow, perhaps timing out or something like that. Still, I’m going to double-check my assumptions, because this is so strange:
I believe Semaphores are automatically unlocked when a macro exits, right? Even if the macro aborts, right?
What about a sub-macro? If I use an “Execute a Macro” action to call a sub-macro, and that sub-macro locks a semaphore, will the semaphore be automatically unlocked when the sub-macro exits?
Are you aware of any situations that would cause a Semaphore to not get unlocked, assuming no macros are running?
I know that the Editor evaluates various things in more-or-less real time, like the value of variables, etc. The Editor won’t lock a semaphore just because I’ve got the Lock Semaphore action in it, right?
No, that is all part of one execution thread. Unless you execute the macro asynchronously, then it will start a new execution thread.
No. And in fact, there is special code that detects the situation where no macros are running and complains if any semaphores are still locked and actively unlocks them. It will complain in the logs if this ever happens.
No. The editor generally evaluates things itself (which is why you'll sometimes see "Not available in the editor" or words to that effect). For some things, it executes an action in the engine (eg finding images), but no semaphore locking will happen form that. And even if it did it would unlock when the execution thread completed which would be more or less immediately.
OK, that tells me something. I kind of doubt it's the cause if this particular issue, but it's good to know.
So that brings up another question, regarding asynchronous execution of macros. Let's say I asynchronously execute a macro passing a parameter. Then, before it finishes, I do it again with a different parameter, so in effect there's two copies of the same macro running, but TriggerValue is different in each of them.
This isn't a problem, right? TriggerValue will work just fine with two different values like this, right?
So if I understand this right if I don't need steps 3 and 5 in this macro because the originating macro will not move on to the next action until the referenced macros are completed? It seems like they are moving on in my case and I am having trouble figuring out how to access certain fields with key commands in the new Google Calendar using Keyboard Maestro.
"To do this, just place a Semaphore Lock Action with the same Semaphore Name as the first action of each Macro that you wish to prevent executing simultaneously." action:Semaphore Lock [Keyboard Maestro Wiki]
As far as the name of steps 3 and 5 go I think I might be reading that wrong. Does it really mater what the name of the semaphore lock is? It could be "Bob" for both the lock and unlock and that just states not to run step 4 until step 1 and 2 are completed right?
Correct. The originating macro will wait for the executed macro to complete.
Unless you are executing the originating macro more than once, or you use that Semaphore Lock somewhere else, those Semaphore Lock/Unlocks are unnecessary.
Of course, the sub-macro might be doing something asynchronously in which case that something might not be finished when the originating macro moves on, but the Semaphore lock would not help with this.
Correct. What the name is is irrelevant - as long as it is the same, and not used anywhere else.
But you could, for example, have a set of macros that all use the same named Semaphore if they might all be operating simultaneously and you don't want them running at the same time.
Thanks for all the answers that clears a lot of things up. It sounds like in my case I rarely will ever need a semaphore lock as mentioned in the help file but knowing that the subroutines will wait until the last thing is run before running on to another subroutine is very helpful.
Oh cool, thanks for explicitly saying that knowing me I probably would have all gave them different names. I always appreciate the detail in your answers!
