Phil Hagelberg <p...@hagelb.org> writes: > But I'm not quite following on the exact problem and specific repro > case; could you clarify?
Yes. When I start SLIME, the Swank back-end starts and presents the Clojure REPL in the *inferior-lisp* buffer. Right after that, the SLIME front-end sends an "Emacs REX" command to the Swank back-end, asking it to invoke the `connection-info' function. At this point, the SLIME front-end has reported that it's trying to connect. The Swank back-end receives the REX request, invokes the `connection-info' method on some thread separate from the thread servicing the Clojure REPL, and hangs in its call to `get-pid'. Because the Swank back-end thread servicing the call to `connection-info' hasn't responded, the SLIME front-end is hung waiting for its REX to complete to gather the `connection-info' result. Not until the SLIME front-end has received that result will it finally announce that it succeeded connecting and present the SLIME REPL. It's not just the SLIME REPL that won't work until that `connection-info' REX completes. Any buffers that attempt to submit forms to Clojure for evaluation will not receive a result; the requests are merely queued because the SLIME front-end has not completed its connection and initial handshake. The call to `get-pid' hangs on its call to RuntimeMXBean#getName() which is part of the first path taken by `get-pid': ,---- | (.. java.lang.management.ManagementFactory | (getRuntimeMXBean) | (getName) | (split "@")) `---- Now, I found a way to unblock that hung call to RuntimeMXBean#getName(): In the Clojure REPL available in the *inferior-lisp* buffer, I can evaluate the following form: ,---- | (.. java.lang.management.ManagementFactory (getRuntimeMXBean) (getName) `---- That evaluation takes place in the thread servicing the Clojure REPL, which is a different thread from the one blocked in the REX call to `connection-info' and, transitively, `get-pid'. The above form evaluates immediately in he Clojure REPL and, as a side-effect I don't yet understand, /also/ causes the call blocked in the Swank REX-servicing thread to complete as well. Hence, `get-pid' completes, the `connection-info' completes, then the SLIME front-end receives its reply and finally sets up the SLIME REPL. From then on, all is well. I've been searching the Web looking for similar complaints about such a call hanging, and so far I've come up blank. Again, note that calling ManagementFactory#getRuntimeMXBean() from the Clojure REPL is not sufficient to unblock the other thread hung in `get-pid'; it takes calling RuntimeMXBean#get() -- actually using the RuntimeMXBean instance -- to unblock the other thread. Perhaps there's some lazy initialization going on in Sun's RuntimeMXBean implementation. > Does it occur with the latest version of swank-clojure? Yes. I'm tracking the tip of the "master" branch via Git. Here's the stack: o swank-clojure Git head. o SLIME Both CVS head and git://git.boinkor.net/slime.git head behave the same way, as the offending calls are in swank-clojure. o Clojure 1.1.0 Downloaded Jar from code.google.com. o GNU Emacs 23.1.1 o Windows XP 32-bit -- Steven E. Harris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
