implement -panic=reset

[stevegt]

I'm suggesting this as a lighter-weight change versus #2331 and #2162. While #2331 looks like it will take a while to resolve and merge due to code growth concerns, #2162 looks like it may not be merged at all due to API issues.

As @ysoldak mentions in #2162, panics happen. In the project I'm working on at the moment, if tinygo hits a runtime error (e.g. slice out of bounds), this can mean pumps left running, valves left open, and chemicals and water all over the floor in the middle of the night when nobody is around.

For any reasonable control system, having some way to implement a fail-safe mode is pretty important. In circuitpython, I can use try/finally to make sure all of those relays are powered off. But this can't be done in tinygo wIth no recover() and with no reset on abort.

If tinygo had a -panic=reset build option (mentioned as a side note in #2331), then I could deal with this by sending the i2c commands to power everything off at the top of main().

Platform: Adafruit qtpy (Cortex M0) --> sparkfun DEV-17047 i2c GPIO expander --> multiple relay coils.

Possible workaround (and a good idea anyway): Add a second qtpy as a watchdog timer. Use it to switch off the power bus for all relay coils on loss of heartbeat from the first qtpy.

[ysoldak]

Possible workaround (and a good idea anyway): Add a second qtpy as a watchdog timer. Use it to switch off the power bus for all relay coils on loss of heartbeat from the first qtpy.

As long as this second watchdog does not die itself :D

[stevegt]

#2331 is merged (yay!), #891 is closed, #2162 appears to be halted, so I'm re-thinking this issue.

• The new recover() support is good, but unless I'm missing something, application devs who want to use defer/recover to reset on panic need to do some careful coding to prevent stack overflows and several other classes of errors; restarting goroutines is a particular headache.
• A -panic=reset flag would be better, but it still might not be enough. Thinking about stack overflows makes me realize that, in Go, stack overflows are not panics, but are instead in a different class of fatal errors; stack overflows might not be expected to be caught by a flag named -panic.

Some questions:

1. Would a -panic=reset implementation also catch fatal, non-panic, non-hardfault errors too, such as stack overflow or OOM? Or should I rename this issue/flag?
2. Is recover() otherwise now reliable on everything but WASM, or are there still known corner cases?