http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/NREPL-8 tools.nrepl <p>If you want to use nREPL on Android (currently only possible with sattvik's fork of Clojure) then you need bigger stack sizes than Android's default 8k to eval even moderately complex expressions. For comparison: A regular JVM on a PC has default stack sizes around 256k ... 512k depending on platform.</p> <p>In nrepl.clj, modify</p> <p>(doto (Thread. r)<br/> (.setDaemon true))))))</p> <p>to read</p> <p>(doto (Thread. (.getThreadGroup (Thread/currentThread)) r "nREPL" 524288) ; 512k generous stack size<br/> (.setDaemon true))))))</p> <p>Note: There are warnings here <a href="http://bit.ly/u86tF1">http://bit.ly/u86tF1</a> about choosing a good stack size but since in practice nREPL seems to have &lt;10 threads running with 1 active client connection we can be generous here.</p> <p>The more advanced version would be to make this somehow configurable but that'd probably be over-engineering things.</p> Android NREPL-8

set stack size for Android

Enhancement Minor Closed Completed Chas Emerick Hank Android Fri, 30 Dec 2011 09:05:19 -0600 Wed, 3 Oct 2012 07:03:59 -0500 Wed, 3 Oct 2012 07:03:59 -0500 0.0.5 0.2.0-beta9 0 0 <p>Noted, thank you. I'll try to make sure a provision for this gets into the next significant release.</p> <p>My first inclination is to ensure that the stack size is configurable; a hardcoded size would likely be just as inappropriate in some environments as the system default.</p> <p>nREPL is now using Clojure's built-in agent threadpools. This should theoretically simplify things for you, correct? i.e. Isn't a patched build of Clojure necessary for use on Android for this stack size issue, among other reasons?</p> <p>The patched build is only necessary for the JVM byte code that the Clojure compiler dynamically generates to be converted to Dalvik bytecode. However adding additional android patches such as configuring the agent threadpool with a larger stack size do make sense. I'm not the official Android Clojure maintainer though &#8211; I guess there isn't an official one really &#8211; so my opinion on this only goes so far.</p> <p>Well, I think you have a solid case for expanding the scope of the android fork, or even for a change to parameterize the threadpools in Clojure itself.</p> <p>I'm going to close this; there's really nothing to be done from within nREPL given that it doesn't maintain its own threadpool anymore.</p> <p>Reopening; since the use of agents was a fool's errand, parameterizing stack size needs to happen.</p> <p>Now that I look at this again, there are a number of options in nREPL to solve this.</p> <p>First, you can provide an <tt>:executor</tt> argument to the <tt>interruptible-eval</tt> middleware. This could be any <tt>java.util.concurrent.Executor</tt>, so you can configure it to use whatever threads you want.</p> <p>Second, and if you want to minimize work and retain as much of nREPL's default configuration otherwise, you can patch in your own thread pool by binding <tt>#'clojure.tools.nrepl.middleware.interruptible-eval/configure-thread-factory</tt> like so:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">(def thread-group ...) (def stack-size ...) (defn android-thread-factory "Returns a <span class="code-keyword">new</span> ThreadFactory suitable <span class="code-keyword">for</span> use with android. This implementation generates daemon threads, with names that include the session id." [] (let [session-thread-counter (AtomicLong. 0)] (reify ThreadFactory (newThread [_ runnable] (doto (<span class="code-object">Thread</span>. thread-group runnable (format <span class="code-quote">"nREPL-worker-%s"</span> (.getAndIncrement session-thread-counter)) stack-size) (.setDaemon <span class="code-keyword">true</span>)))))) (with-bindings {#'clojure.tools.nrepl.middleware.interruptible-eval/configure-thread-factory android-thread-factory} (clojure.tools.nrepl.server/start-server ...))</pre> </div></div> <p>The above totally untested, but I hope you get the idea. Give it a shot, and let me know how it goes. I'm going to take off this issue's fix target for now.</p> <p>I hear good things at this point about people connecting to nREPL endpoints running on Android. Please file another issue if this or other Android-specific problems arise in the future.</p> Global Rank