Thoughts on the practicalities of concurrent macro execution

[Cory]

In the beginning there was ME3 and lo one could only run one macro at a time. Then ISS created light and now we can run more than one at once. But like with anything power is accompanied by danger and this is what concerns me today and I would like to know all of your comments as to the practical implementations of MEP with possible concurrent macros.

 

When importing my first macros I saw the prompt to add the player locks and thought that we shouldn’t need this with properly designed MEP macros but now I’m not so sure. I mean obviously having a scheduled macro that opens a web page and does stuff would be dangerous but I was thinking macros that did not function in the user interface should be fine. But then I got to thinking about global variables and now I have more to worry about.

 

I want to ask some specific questions in other posts but in general I was hoping you all would comment on your thoughts and possible resolutions to make myself a sort of ‘best practices’ guide for concurrent macro running. Obviously locking the player in all means there will be no problem but the player locking is one way so this could preclude the sensible application of some macros being able to run concurrently. For instance one complaint I get from some of my users is that while running a macro to dispose of some document they want to run another macro to look something up quick. If I lock the first one then I can’t take advantage of concurrent runs but if I unlock it now ANY other macro could accidentally run and step on what the user is doing. So what are you guys doing and what thoughts have you had on the matter.

 

It’s a great tool but suddenly I find my mind boggling at all the possible problems of implementing it. I really am starting to think that implementing concurrent execution is really a Pandora’s box unless we could have more granular control. IE opening the door to all macros unconditionally is just too dangerous. I might have to regress to the dark for distributed user macros.

 

You might want to consider my other posts regarding the following issues before responding.

• Macro activating other macros
  
• Player Lock a one way street?
  
• Player Lock function questions.
  
• Are global variable global to concurrent runs?
  

[Jeff Cleveland]

Cory,

 

Way back when I was a practitioner in the computer engineering field, we learned about concurrent processes and the need for control of multiple processes that needed access to a service where only one process at a time could be allowed access to the service at a time. This was done with code that controlled access to what is called critical sections. Access to the service was controlled by a "named" lock, a different "name" for each service. Perhaps what we really need is a "named" lock capability. This is usually provided by computer language being used or the operating system.

 

I think this might be a solution to the problems outlined.

 

Jeff

[Cory]

I was thinking the same thing. Certain combinations of macros are fine while others are deadly and only having one way control isn't adequate. I'm thinking that I could make conditions for the Player Lock based on a table of macro names to control this. I could have the default be locked and I could simply create entries where one macro, depending on the conditions, could be allowed to run concurrently. Then again this is a whole lot more to maintain. But thanks for the input.

[Cory]

You know I was really hoping to get more response out of this as I considered it a huge issue that might affect us all. To keep tally we have established that variables with the same names in concurrent macros can not mess with each other (a good thing) but that concurrent macro execution does run the risk of having macros execute other macros (a very bad thing). The other two questions have gone without response. [sigh] C'est la vie.

 

I need to make a decision and I think one of the biggest issues is the player lock which went unanswered. So as it is I think the player lock being a one way street is a deal breaker. Half the time this seems a sensible solution but it also seems to me that half the time one wants to do ti the other way. EG a command that one could use to prevent a macro from running if other macros are already running. Also we can only allowing all their macros to run, not just some. So my final analysis is that since we don't have the necessary control concurrent macro is a Pandora's box for large distributed end user macro files. IOW we can't lock it down in a useful way and macros can unintentionally activate other macros. I can think of some possible ways to do a home brew macro interaction table but I think this is simply too much work for the benefit. Too bad, it seemed like such a cool feature.

[paul]

In other words <g>!

 

We've gone from a simple single-process macro environment to a complex multiple-process macro environment, i.e. the sort of environment that professional software writers are well-accustomed to. So we now need to design and write our macros in a more structured (professional?) way than before.

 

But, surely, that's not a cause for complaint, is it? If we don't want to, or cannot, learn to write our macros in a more structured way, then simply stick to what we already know and continue to run our macros one at a time. But if we dare to venture outside of our playpen, then perhaps we can make exciting discoveries on the way. It all depends on where you're coming from and on where you want to get to. It's invalid to complain about, say, the English language when faced with a decent dictionary; I don't need to know every word in order to be able to speak and write English; but if I do take the time to learn more words, then I may become more articulate, and express more complex ideas than before. But no-one is forcing me.

 

ME4 offers far more complex features than ME3. Complex features need to be learned. That's inescapable. There's no magic bullet.

[terrypin]

In other words <g>!

 

We've gone from a simple single-process macro environment to a complex multiple-process macro environment, i.e. the sort of environment that professional software writers are well-accustomed to. So we now need to design and write our macros in a more structured (professional?) way than before.

 

But, surely, that's not a cause for complaint, is it? If we don't want to, or cannot, learn to write our macros in a more structured way, then simply stick to what we already know and continue to run our macros one at a time. But if we dare to venture outside of our playpen, then perhaps we can make exciting discoveries on the way. It all depends on where you're coming from and on where you want to get to. It's invalid to complain about, say, the English language when faced with a decent dictionary; I don't need to know every word in order to be able to speak and write English; but if I do take the time to learn more words, then I may become more articulate, and express more complex ideas than before. But no-one is forcing me.

 

ME4 offers far more complex features than ME3. Complex features need to be learned. That's inescapable. There's no magic bullet.

 

I've no experience yet of concurrent operation with ME Pro so I'm hesitant to contribute at all. However, I've been bitten a few times when accidentally running macros from another application, Stiletto, and also when when both ME 3 and ME Pro were loaded. So I'll be very slow to dip my toe in this particular pond! However ...

 

1) I think Cory's right about that two-way issue on Player Lock. That seems a tool missing from the bag. But there's been no response from ISS yet so maybe I've misunderstood something fundamental (not for the first time!).

 

2) Therefore, while agreeing about the potential for all sorts of Good Things, I think Paul's analogy is flimsy. If say all the verbs in the dictionary had been omitted, either by accident or lack of thorough planning, then its users would have problems. And, if they weren't aware of the problem, their spoken and written work could prove embarrassing.

 

3) My only significant new point is this: IMO some worked examples illustrating how concurrent use works are badly needed in Help.

 

--

Terry, East Grinstead, UK

[Cory]

That seems a tool missing from the bag.

Yeah! I'm going to use that one. My background is in Engineering, design and good ol' knuckle busting mechanics and slap happy fabrication so tools are a huge part of my life. And of course I consider ethereal tools some of the most important. A while back I bought a set of metric wobble sockets from Sears and tossed them in my roll-away. Some time later I was working on a car and found an opportunity for use. I grabbed them and started looking up the rail. 10, 12, 13, 15, 17... What? Where's the 14mm? Every metric car except some Europeans use the 14 instead of the 15. IOW 75% of the metric cars need that 14mm. This is how I feel with MEP. We got a lot of new cool tools but it's like looking at a peg board filled with cool tools but all the sets seems to have empty pegs with empty outlines making it very frustrating and often impossible to utilize. Like having a multimeter with no leads. I could improvise with some scraps of wire but...

 

But I do know that at least some of the ISS boys are aware of these shortcomings and I believe they will try to fill those voids soon. I know when I design things for myself then try to give it to someone else I forget some obvious things but I was too close to see the problems. Our job is to point out those empty outlines on the peg board.

 

BTW the socket set was not missing the 14mm, it was never included as part of the set.