A question about clojure.core.async.impl.dispatch/executor-for - currently it's memoized, meaning that there is no officially supported way to change the ExecutorService for a given workload once it's retrieved once. The system property clojure.core.async.executor-factory does provide more flexibility than there was pre-1.8, but if I want to replace it or revert to the default, I seem to need to mess with the private impl.dispatch namespace.
Was this considered during the design of 1.8? Or does this sound like a niche scenario?
Thanks for the insight, btw!
One additional note: the hardcoded memoization also means I cannot be sure that I am in control of the executor-factory if I want to set the system property from code
The intent is that you set the executor-factory property
What are you worried about messing with?
I understand that's the intended interface. It's just that even if I reset that property, it won't take effect in the same process unless I redefine executor-for
The broad usecase is testing where I don't want to restart the process between usages of different executor-factories
Memoization is a good default and the option to use that property is useful. I just wish there was a supported way of opting out of memoization
Oh, we were not trying to support that
Would you consider that actively discouraged or just niche enough to never occur to you?
(using different executor-factories throughout the lifetime of a process)
Not supported
Is it just for testing?
Mainly yes. I'm migrating some projects from 1.7.701 to 1.8.x and one of the non-trivial connection points is that these projects injected their own Executors to customize things like thread name and pass MDC around. Pre-1.8 this was possible using set-var-root and depending on impl namespaces directly.
1.8 provides the property so that's good for prod use, I just want to set up some tests around this.
Another potential usecase is that I want to put this customization into an internal common library, providing a default value to the property using System/setProperty - but if that is loaded too late during startup, the core.async default one might already have taken effect.
(and I'd prefer to do all this while also breaking our direct dependencies on implementation details)