Closed samaaron closed 13 years ago
A thread pool is certainly possible, though this is the first I've heard of too many threads being an issue. Are the compilation threads staying around longer than they should?
No, they're not sticking around longer than necessary and I'm probably barking up the wrong tree with this "issue" anyway. Let me explain and tell me where my reasoning is flawed...
I'm using Clojure to trigger synthesisers and occasionally I see hiccups in the triggering. i.e. they trigger later than expected - like the system paused for a moment, buffered all triggers and executed them in much close succession than requested at a later time than expected.
My first thought was that the GC was kicking in and stopping the world. I've since heavily tuned it and monitored it and am pretty confident it's not the issue.
Now I'm looking at the thread creation count and it's extremely high. It seems that for each synth trigger 4-5 JVM threads are created which feels wasteful (although I may be entirely wrong here). I'm not too concerned about the memory usage of threads, and they're extremely short-lived anyway, rather I'm concerned about the potential cost in terms of "trigger time" - the time between triggering a synth in emacs and the actual synth being triggered in the underlying sound synthesis engine which relies on these new threads (both in swank-clojure and overtone).
I was wondering whether the creation of threads is a potential "stop the system" event. i.e. I assume the responsibility for the creation of threads is handed to the kernel which could be busy doing other things.
I'm struggling to find useful resources to enlighten me as to what's really going on here. Perhaps you have more of an idea than myself?
It appears that every time I evaluate a form in emacs at least one new thread is created on the JVM. Is this strictly necessary? Would it be possible to use a thread pool?