gcode interrupts

[bwnance]

adds a gcode command: HEATER_INTERRUPT

also allows any command with INTERRUPT in it to skip mutex

[dalegaard]

Hi,

Maybe it makes sense with multiple prioritized queues?

The main user gcode input from socket could be executed on one queue with high priority, and the gcode coming in from virtual_sdcard could be using a second lower priority queue. Each gcode button could also get their own high priority queue.

The interrupt hold mechanism seems racy to me. I've previously thought about a solution for doing interrupts for currently running commands, by having a generation counter that INTERRUPT would increment. Anything waiting would sample the counter before starting wait, and if the counter changes an interrupt has been sent(I would wrap this in a helper function that long waiters can use). I'm not sure if it is required to do this, but it feels like it will better handle potential race conditions.

I think keeping the mutex is probably wise, but add the ability to have "naked" command handlers that don't require taking the mutex - these are allowed to execute immediately when they arrive at the front of their queue. This could be e.g. M112, INTERRUPT, and maybe gcode buttons?

Just some thoughts.

Best regards,
Lasse

[bwnance]

@dalegaard yeah, after some thought overnight, this "mutex-less" approach is a bad idea and veery dangerous (and not in the good way :)

I was discussing pretty much exactly the "naked" mutex option earlier with @rogerlz and @Piezoid and it seemed like the simplest way forward for now.

Agreed that the INTERRUPT_HOLD implementation is suboptimal - i like that counter option! i'll take a swing at implementing that.

@Piezoid also suggested a second mutex - but i think that for now, that's probably not required - especially if the initial goal is just for high-priority commands to run without mutex.

One weird piece of this, which might just be an inevitability, is the behavior of an INTERRUPT nested within macros - my initial thought was to search through the lines for a match on the "naked" commands - but if a naked command is buried within a macro we would have no idea it was there until its direct parent macro was executed.