Add reset-executor! and shutdown-executor! to re-frame.interop

[lowecg]

For #809

Executor Service Lifecycle Management
Added two functions to manage the executor service lifecycle in re-frame/interop:

reset-executor! - Creates a fresh single-threaded executor when needed
shutdown-executor! - Cleanly terminates the executor with configurable timeout

Why?
These functions enable proper cleanup in short-lived processes like AWS Lambda, CLI runs and tests. Without explicit shutdown, the non-daemon executor threads prevent the JVM from exiting cleanly.

Adding the following to a test ensures clean shutdown:

(ns my-ns
  (:require
    [clojure.test :refer :all]
    [re-frame.interop :as interop]
    ...))

(use-fixtures :once
              (fn [f]
                (f)  ; runs all tests
                (interop/shutdown-executor! 100)))

[kimo-k]

some discussion - https://clojurians.slack.com/archives/C073DKH9P/p1733141055817809

[lowecg]

I've removed reset-executor! from the PR. Lambda functions work fine without interacting with the scheduler

[lowecg]

Hi Eugene, I have read the discussion - thank you all for your inputs! The point about not exposing an API to the executor was compelling, and I fully agree there. In terms of removing the executor, that makes sense given that it appears not to be emulating CLJS behaviour, in fact it's changing it. Not having the executor would prevent the need for a workaround, and would prevent users walking into the issue in the first place. Would you like me to change the PR to remove the executor and change next-tick as per the discussion? Cheers, Chris

…

On Wed, 4 Dec 2024 at 10:29, Eugene Pakhomov ***@***.***> wrote: @lowecg <https://github.com/lowecg> Have you seen the discussion on Slack? Do you have any thoughts on getting rid of the executor completely and running all re-frame stuff in CLJ on the main thread? — Reply to this email directly, view it on GitHub <#810 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHCVNVYTY6Y35QXVHUFMX32D3KRZAVCNFSM6AAAAABR6CQQQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJWHA4TANBRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[p-himik]

@lowecg Ah, sorry for the noise - I removed my message pretty much immediately after I realized that I've posted it on the PR and not on the issue page.

As for what to do - that would be up to @kimo-k or someone else from Day8. But were it my own PR, I would definitely go the route of removing the executor, the thread for next-tick, and the associated locking that was added only to make the thread behave properly.

[kimo-k]

Regarding locking: #469 #471

[lowecg]

@p-himik @kimo-k Thank you for your continued input on this. I've removed the executor and locking added for #471. The change fixes the repo cases I'd raised for #809. I've left the test from #469 since it shows the simplified next-tick is working as intended in this regard.

Here's a short summary for the change, I hope it sufficiently captures your thread on Slack:

The single-threaded executor in the JVM implementation of re-frame is being removed to simplify the code and resolve concurrency issues. Originally added to mimic JavaScript’s single-threaded behaviour, it introduced unnecessary complexity and inconsistent behaviour, such as race condition, unpredictable event handling orders and process hang when running tests from the CLI.

Benefits to removing the executor:

• Simpler Code: Eliminates threading and locking overhead.
• Consistent Behaviour: Aligns more closely with JavaScript semantics.
• Improved Reliability: Reduces concurrency issues in tests and development.
• Streamlined Focus: Keeps re-frame’s JVM use focused on testing, avoiding unsupported multithreaded scenarios.