[Feature request] reentrancy macro guard

[kareltucek]

Making sure that 'daemon' macros are ran only once is actually a common usecase. It is easy to handle via variables, but adds a nontrivial amount of clutter into the code.

So the idea is to introduce some condition that can easily check whether there is already another instance of the same macro running. So the resulting syntax may be:

ifReentrant break
...

Or

ifNotReentrant {
...
}

Or maybe (this is ambiguous, compared to code that should be ran only once, so probably not).

once {
}

@mhantsch @firngrod @mondalaci any opinion on preferred syntax?

[mhantsch]

In other words, a Singleton?

Lots of questions pop into my mind:

How do you expect to handle macros that exec others? They would still run in the same macro slot, but it might be a different one than the macro that started it.

ifNotReentrant final exec theOtherMacro

(TheOtherMacro runs for a long time)

How would that detect reentrancy?

Do we need to name the semaphore, and default the name to the current macro name?

ifNotReentrant semaphoreName mySingleInstanceThing final exec theOtherMacro

How to vacate the semaphore?

[kareltucek]

The idea was to use macro index, and make it a simple condition.

I.e., yours exec would not get detected.

No, I definitely not want to be introducing new objects (named semaphores or whatever).

I might add a scope state bit and forbid exec macros in such a scope to prevent you from shooting yourself in the foot...

[kareltucek]

A naming Idea I now lean towards is: oneInstance. Or maybe singleton

[firngrod]

I will not comment on complexities of implementation, yet at least, but in the spirit of making it readable to non-technical people how about ifAlreadyRunning/ifNotAlreadyRunning?

[firngrod]

Maybe if[Already/Macro]Running [macroName, default current]

[mhantsch]

ifMacroRunning with optional macro name, that's my favourite. Works for both cases: this macro itself, and exec/fork instances.

ifNotMacroRunning {
   // do something long but single instance only
} 

ifNotMacroRunning myBackgroundJob final fork myBackgroundJob

[firngrod]

Is final fork not very identical to exec?
Alternatively a very dangerous piece of flatware.

[mhantsch]

I guess the difference is that it starts the new macro in a new macro slot, so the slot number changes. But that's the only (internal) difference. Externally it should behave the same, I would think.

[kareltucek]

Is final fork not very identical to exec?

Not really iirc. final fork runs in a new slot and doesn't inherit the macro's state and history.

Exec runs in the same slot and inherits most of the macro state. (I am not sure how much is cleared, but in case of fork, I expect only little context to get inherited, while in exec case, I expect most of the context to get inherited.)

Alternatively a very dangerous piece of flatware.

Sorry, I don't undesrtand?