Others will have more idea, but my observation is that it is evaluated
once, so a namespace which is required by multiple namespaces will only
be evaluated once. Should you explicitly re-evaluate it then it will of
course be evaluated again.
You might be interested in reading Stuart Sierra's 'reloaded workflow'
and using the resultant Component library which has some input on this.
The other machinery you might want to look at is defonce, which does
exactly what it says :-).
To give you peace of mind you could experiment with:
(ns a)
(def m (atom 0))
(swap! m inc)
(ns b
(:requires [a]))
(ns c
(:requires [a]))
And then load 'a' and 'b'. My expectation is that a/m will be 1
As I say, this is from observation rather than inspecting the underlying
machinery.
HTH.
lvh writes:
> Hi,
>
>
> Suppose I have a namespace that has some ns-level side effect, e.g. `(def
> atom {})`.
>
> 1. When is that executed? How often? (I think, from observation, that the
> answer is “when it is first required”, and “exactly once”; but it’s important
> for the correctness of my program that this is the case.)
> 2. Is there a mutex preventing multiple threads from attempting that at the
> same time? If so, is that an accident, or a language guarantee?
>
> I don’t know if it matters, but in this case the side effect will be a method
> call on a jnr-ffi binding, so internally it will go off and synchronously
> initialize a C library. It’s fine if it gets called multiple times, but only
> if it has been executed by exactly 1 thread first. (It sets some state to
> signify that it’s initialized; if you call it when it’s already initialized,
> it just exits. It is _not_ re-entrant.)
>
> If these guarantees don’t hold, is there a convenient/canonical way to
> execute that side-effect synchronously? I’d like to prevent users of my
> library to have to remember to call an init fn in their main- if I can.
>
>
> thanks
> lvh
--
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
---
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 clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
