I think it would be nice if inheritable-var would set! the future executor
service on load, so the user doesn't have to. This way it will just work
with future also. Just my 2 cent.
Here's how to reproduce the issue with core.async:
(let [t 1000]
(dotimes [x t]
(let [foo (inheritable-var (constantly "Main"))
chan (async/chan)]
(inheritable-binding [foo "In chan Thread."]
(async/go
(async/>! chan @foo))
(let [res (async/<!! chan)]
(when (= x (dec t))
(print res)))))))
On Saturday, 29 July 2017 23:52:44 UTC-7, Jiacai Liu wrote:
>
> For your first example, we should decorate the executor future use, see
> TransmittableThreadLocal
> doc
> <https://github.com/alibaba/transmittable-thread-local/blob/master/README-EN.md#22-decorate-thread-pool>
>
> (let [foo (inheritable-var (constantly "Main"))]
> (set! clojure.lang.Agent/soloExecutor (->inheritable
> clojure.lang.Agent/soloExecutor)) (inheritable-binding [foo "In future
> thread"]
> @(future @foo)))
>
> For core/async example, this should return In chan Thread, are you using
> v0.1.3 ?
>
> (let [foo (inheritable-var (constantly "Main"))
> chan (async/chan)]
> (inheritable-binding [foo "In chan Thread."]
> (async/go
> (async/>! chan @foo))
> (async/<!! chan)))
>
> I will add binding conveyance and usage to decorate executor when using
> thread pool in my doc
>
> Many thanks. 👍
>
> On Sunday, July 30, 2017 at 1:28:46 PM UTC+8, Didier wrote:
>>
>> Your doc says this doesn't work with dynamic binding:
>>
>> (def ^:dynamic *foo* 5)
>> (defn adder
>> [param]
>> (+ *foo* param))
>> (binding [*foo* 10]
>> (doseq [v (pmap adder (repeat 3 5))]
>> (println v)))
>>
>> But it does since Clojure 1.3. They added binding conveyance:
>> https://github.com/clojure/clojure/blob/master/changes.md#234-binding-conveyance
>>
>> This means that in Clojure 1.3+, when using dynamic binding and future,
>> agent, pmap or core.async, child threads will inherit the bounded vars
>> properly.
>>
>> You might want to make that clear in your doc.
>>
>> I also believe there's an issue with your library, this does not work:
>>
>> (definheritable foo "Main thread.")
>> (inheritable-binding [foo "In thread inside future, running on Clojure
>> ThreadPools."]
>> @(future @foo))
>>
>> It also doesn't seem to play nice with core.async, whereas dynamic vars
>> do:
>>
>> (let [chan (async/chan)]
>> (inheritable-binding [foo "In chan Thread."]
>> (async/go
>> (async/>! chan @foo))
>> (async/<!! chan)))
>> => CompilerException java.lang.RuntimeException: Unable to resolve
>> symbol: foo in this context
>>
>> (def ^:dynamic bar "In main thread.")
>> (let [chan (async/chan)]
>> (binding [bar "In chan Thread."]
>> (async/go
>> (async/>! chan bar))
>> (async/<!! chan)))
>> => "In chan Thread."
>>
>>
>>
>> On Saturday, 29 July 2017 19:37:13 UTC-7, Jiacai Liu wrote:
>>>
>>> Thanks for your tips.
>>>
>>> I have updated my code to wrap TransmittableThreadLocal
>>> <https://github.com/alibaba/transmittable-thread-local/blob/master/README-EN.md>,
>>> an
>>> enhanced version of InheritableThreadLocal, to solve threadpool problem.
>>>
>>> On Sunday, July 30, 2017 at 3:11:59 AM UTC+8, Didier wrote:
>>>>
>>>> InheritableThreadLocal is not safe to use with ThreadPools. And a lot
>>>> of the Clojure parallel constructs rely on ThreadPools.
>>>>
>>>> I'd recommend you rely on dynamic Vars instead and use bound-fn when
>>>> you want child threads to inherit parent's bindings.
>>>>
>>>> If you knew this already, then I see no harm in using
>>>> InheritableThreadLocal, but just be sure you understand its risk. In most
>>>> cases, it is unsafe.
>>>>
>>>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
