[NREPL-39] Using functions reading from *in* causes "java.io.IOException: Write end dead" Created: 03/Feb/13 Updated: 07/Apr/13 Resolved: 21/Mar/13
|Reporter:||Adrian Bendel||Assignee:||Colin Jones|
When calling (read-line) from lein repl or ccw repl, waiting around four minutes (on my machine),
While googling a bit on this and without concrete knowledge of the implementation in nrepl,
|Comment by Colin Jones [ 06/Mar/13 5:46 PM ]|
I found this related article: http://techtavern.wordpress.com/2008/07/16/whats-this-ioexception-write-end-dead/
So it seems like we may need something a little more robust. I'm thinking just a LinkedBlockingQueue that gets written to on input, with a Reader proxy over the top to hook up to Clojure's LineNumberingPushbackReader. I've started fiddling with that idea, passing most of the tests already, and I think this is the right path to go down in general. Yell at me if you see a problem with this plan.
|Comment by Chas Emerick [ 07/Mar/13 4:50 AM ]|
I had no idea that PipedReader & co. actually track the threads that touch them. That makes them entirely inappropriate for the *in* case.
+1 to your plan, thanks for chasing this!
|Comment by Colin Jones [ 08/Mar/13 3:28 PM ]|
OK, this works for me against REPLy.
I'd have preferred to avoid the dynamic binding (skipping-eol), but I haven't been able to think of another way to accomplish what it does. The problem is that we don't want to send another :need-input message just to clear newlines, but we don't have any visibility into what's in the LineNumberingPushbackReader's buffer (neither the full deal, nor the pushback). My initial thought was to replace the LineNumberingPushbackReader directly, with a custom thing, but I think the assumptions around that class in `read` and `read-line` are too concretely baked in to allow it (especially before 1.5, when the buffer size became configurable).
And there's no room for adding bits to the Reader interface, so in order to effect a behavior difference in the Reader, depending on what the high-level state is, I don't know that there are any options aside from dynamic binding or an atom (and of the two, a var seemed more robust, no worries about finally & friends).
|Comment by Colin Jones [ 21/Mar/13 11:39 PM ]|