I just tried with boot real:
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=> (.getId (Thread/currentThread))
> 34
> boot.user=>
That seems pretty weird. I can't reproduce it. I'm using lein 2.5.2.
On Tuesday, February 9, 2016 at 12:19:09 PM UTC-6, Nathan Marz wrote:
>
> I was doing some work that involved the use of thread locals, and I
> noticed that within a REPL session (launched via 'lein repl') my thread
> locals
yep..now I get the same weird result with boot too:
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
boot.user=> (.getId (Thread/currentThread))
34
I should clarify that the thread id doesn't change instantly, it seems to
change when I've left it idle for a bit. Also on lein 2.5.2.
On Tue, Feb 9, 2016 at 1:45 PM, Mimmo Cosenza
wrote:
> I just tried with boot real:
>
> boot.user=> (.getId (Thread/currentThread))
>
These would be consistent with having a background thread pool where the
ttl expired that were running your repl commands. I was able to repro in
lein after waiting a bit.
The default clojure.main/repl doesn't do anything like that, but maybe lein
and boot do (perhaps via nrepl or something?)
I was doing some work that involved the use of thread locals, and I noticed
that within a REPL session (launched via 'lein repl') my thread locals
would reset themselves to their initial value. I did some digging and found
that the thread id keeps changing within a single REPL session, e.g.:
I'm pretty fuzzy on how nREPL works, so I might be getting it wrong here
... but I think it processes each method through a `future`. See:
https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj#L28
All of the nREPL operations are async, AFAIK, and I
Ahem.
"method" -> "message"
Jony
On Wednesday, 10 February 2016 00:35:16 UTC, Jony Hudson wrote:
>
> I'm pretty fuzzy on how nREPL works, so I might be getting it wrong here
> ... but I think it processes each method through a `future`. See:
>
>
>
Yea, that code seems to explain the behavior we're seeing. I opened an
issue for this: http://dev.clojure.org/jira/browse/NREPL-80
On Tue, Feb 9, 2016 at 7:38 PM, Jony Hudson wrote:
> Ahem.
>
> "method" -> "message"
>
>
> Jony
>
>
> On Wednesday, 10 February 2016 00:35:16