esp8266: Disallow recursive calls to REPL.

Before this change, if REPL blocked executing some code, it was possible
to still input new statememts and excuting them, all leading to weird,
and portentially dangerous interaction.

TODO: Current implementation may have issues processing input accumulated
while REPL was blocked.

esp8266/uart.c

@@ -234,6 +234,17 @@ void mp_keyboard_interrupt(void);
 
 int interrupt_char;
 void uart_task_handler(os_event_t *evt) {
+    if (pyexec_repl_active) {
+        // TODO: Just returning here isn't exactly right.
+        // What really should be done is something like
+        // enquing delayed event to itself, for another
+        // chance to feed data to REPL. Otherwise, there
+        // can be situation when buffer has bunch of data,
+        // and sits unprocessed, because we consumed all
+        // processing signals like this.
+        return;
+    }
+
     int c, ret = 0;
     while ((c = ringbuf_get(&input_buf)) >= 0) {
         if (c == interrupt_char) {

lib/utils/pyexec.c

@@ -277,12 +277,17 @@ input_restart:
     }
 }
 
+uint8_t pyexec_repl_active;
 int pyexec_event_repl_process_char(int c) {
+    pyexec_repl_active = 1;
+    int res;
     if (pyexec_mode_kind == PYEXEC_MODE_RAW_REPL) {
-        return pyexec_raw_repl_process_char(c);
+        res = pyexec_raw_repl_process_char(c);
     } else {
-        return pyexec_friendly_repl_process_char(c);
+        res = pyexec_friendly_repl_process_char(c);
     }
+    pyexec_repl_active = 0;
+    return res;
 }
 
 #else // MICROPY_REPL_EVENT_DRIVEN

lib/utils/pyexec.h

@@ -42,6 +42,7 @@ int pyexec_file(const char *filename);
 int pyexec_frozen_module(const char *name);
 void pyexec_event_repl_init(void);
 int pyexec_event_repl_process_char(int c);
+extern uint8_t pyexec_repl_active;
 
 MP_DECLARE_CONST_FUN_OBJ(pyb_set_repl_info_obj);