(reset) is not thread-safe

[ivan]

Calling jig's (reset) near-simultaneously from two nREPL connections results in a very long series of tracebacks that won't go away, even on the next (reset).

Some sample Python code to call (reset); run two of these in the background: https://www.refheap.com/20997/raw The tracebacks: https://www.refheap.com/20996/raw

I can confirm that using (locking ...) in reset fixes the problem, but I don't know if that's where it should be fixed.

(def reset-monitor (Object.))

(defn reset
  "Stops the system, reloads modified source files, and restarts it."
  []
  (locking reset-monitor
    (stop)
    (refresh :after 'user/go)))

[malcolmsparks]

Thanks for this - it's a nice solution for ensuring that two resets don't happen at the same time. Some components open and close network ports, so it makes no sense for these components to be thread-safe - it's important to ensure that resets are serialized and your monitor solution does this. I'll build this in to the next release of Jig.