r your comments. As suggested I ran a small benchmark of both
> > versions. Turns out that the difference between (ref-set ref @ref) and
> > ensure is huge ...
> > I'm running clojure 1.8.0 by the way. According to VisualVM the (ref-set
> ref @ref) version spends most
2017-03-09 12:34 GMT+01:00 'bertschi' via Clojure :
> Thanks for your comments. As suggested I ran a small benchmark of both
> versions. Turns out that the difference between (ref-set ref @ref) and
> ensure is huge ...
> I'm running clojure 1.8.0 by the way. According t
Thanks for your comments. As suggested I ran a small benchmark of both
versions. Turns out that the difference between (ref-set ref @ref) and
ensure is huge ...
(defn write-skew [de-ref]
(let [cats (ref 1)
dogs (ref 1)
john (future
(dosync
2017-03-06 12:06 GMT+01:00 'bertschi' via Clojure :
> From the docs it says "Allows for more concurrency than (ref-set ref @ref)".
> I would read that as "runs at least as fast as (ref-set ref @ref)", but
> using (ref-set dogs @dogs) instead of (ensure d
https://clojuredocs.org/clojure.core/ensure
Must be called in a transaction. Protects the ref from modification
by other transactions. Returns the in-transaction-value of
ref. Allows for more concurrency than (ref-set ref @ref)
This can be read in two contradictory ways. Protecting a ref
(swap! count-write-skews inc)))
@count-write-skews))
(write-skew-demo)
When I try to fix this program using ensure, i.e. using (ensure dogs) in
john and (ensure cats) in mary, I find that it sometimes runs very slow.
>From the docs it says "Allows for more concurrency than (
sed.
>>
>>
>>
>>
>> On Tuesday, December 10, 2013 3:30:09 PM UTC+5:30, Himakshi Mangal wrote:
>>
>>> Hi,
>>>
>>> I was using clojure to upload the dbpedia datasets into neo4j.
>>>
>>> Unfortunately, my system hanged and i h
the execution of program again it shows this error:
>>
>> 'neostore' does not contain a store version, please ensure that the
>> original database was shut down in a clean state.
>>
>>
>> How can i solve this error so that i can start the uploading
anged and i had to restart everything. Now, if i
> start the execution of program again it shows this error:
>
> 'neostore' does not contain a store version, please ensure that the
> original database was shut down in a clean state.
>
>
> How can i solve this error so
was using clojure to upload the dbpedia datasets into neo4j.
>
> Unfortunately, my system hanged and i had to restart everything. Now, if i
> start the execution of program again it shows this error:
>
> 'neostore' does not contain a store version, please ensure that t
;> Hi,
>>
>> I was using clojure to upload the dbpedia datasets into neo4j.
>>
>> Unfortunately, my system hanged and i had to restart everything. Now, if
>> i start the execution of program again it shows this error:
>>
>> 'neostore' does not con
> Unfortunately, my system hanged and i had to restart everything. Now, if i
> start the execution of program again it shows this error:
>
> 'neostore' does not contain a store version, please ensure that the
> original database was shut down in a clean state.
>
>
&g
Hi,
I was using clojure to upload the dbpedia datasets into neo4j.
Unfortunately, my system hanged and i had to restart everything. Now, if i
start the execution of program again it shows this error:
'neostore' does not contain a store version, please ensure that the
original da
On the Clojure side the only thing you can do is to serialize writes to the
resouce (the db connection). So at most one thread can be performing an
update operation, at a given time. You can increase concurrency by
mantaining "read-only" db connections (most likely in an
ad-hoc/by-convention ma
Use mongo findandmodify command. Only way I know
On Mar 6, 2013 8:36 AM, "bruce li" wrote:
> Hello,
> I'm working on a piece of code that uses congomongo to access mongodb.
> What I want to implement is to use one collection of the DB as a
> queue(let's say, it's called "task").
>
> Using congomo
Well, traditional transactions map to refs in Clojure.
You could use a ref, as in any transactional stuff must be performed
in a dosync
form.
However, using a agent is a much cleaner solution for your needs IMHO.
An agent, by definition, can be executing only one operation at a given
time, and oth
Hello,
I'm working on a piece of code that uses congomongo to access mongodb. What
I want to implement is to use one collection of the DB as a queue(let's
say, it's called "task").
Using congomongo, it's easy to fetch a task that is of status :queue : (def
t (fetch-one :task :where {:status :queue
Looks like refs are not particularly the best tool for the job in this case
- those values aren't going to change a lot right? And they could be
expressed as a single hashmap - removing the needs for transactionality.
Answering to your question, it is impossible to reach the (when...) without
t
I would like to connect to MongoDb with the following code, but I am
worried about the side-effecting code that comes right after the
dosync:
(def which-database-to-use (ref false))
(def which-collection-to-use (ref false))
(defn connect-to-server []
(mg/connect!))
(defn set-database-to-use [
Yes, pmap behaves as map with respect to the ordering of the elements
of the resulting sequence.
// ben
On Sat, Aug 11, 2012 at 9:29 PM, Jim - FooBar(); wrote:
> Hi all,
>
> I was wondering what assumptions does pmap take with regards to the ordering
> of the resulting seq? Can I assume it retai
Hi all,
I was wondering what assumptions does pmap take with regards to the
ordering of the resulting seq? Can I assume it retains the original
ordering or does it just cons whatever future returns earlier? In other
words can I do this and feel safe?
--
Hello.
In clojure-contrib 1.2, lazy-xml/emit outputs XML in most cases.
However, if it gets HTML or similar format data, the output format is
switched to HTML.
That makes some differences at least on OpenJDK6.
1. In XML mode, output doesn't contain any extra \n if :indent is
skipped. In HTML mode
I follow this thread, but haven't read Clojure's source. I have a
similar question -
http://groups.google.com/group/clojure/browse_thread/thread/46415b89c7b311f6,
but haven't got any responses yet.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To p
On Wed, Sep 15, 2010 at 10:44 AM, Stuart Halloway wrote:
> Encounter time. I am sitting next to Rich as I write this.
>
Guaranteed or implementation detail?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojur
Encounter time. I am sitting next to Rich as I write this.
Stu
> Ok, I have a 1 and 2 :)
>
> So is it pessimistic or optimistic? So encounter time ensure or commit
> time ensure?
>
> On Sep 14, 9:36 pm, Stuart Halloway wrote:
>> Actually, the second one is basically
conflicts on the Ref. The current
transaction will be able to set a new value for the Ref later in the
transaction as long as other transactions haven't called ensure on
the same Ref.
This calls the touch method on the Ref which passes the Ref object to
the doEnsure method of the LockingTransa
Ok, I have a 1 and 2 :)
So is it pessimistic or optimistic? So encounter time ensure or commit
time ensure?
On Sep 14, 9:36 pm, Stuart Halloway wrote:
> Actually, the second one is basically it. (Except that I don't know the
> Oracle reference, so can't speak to that.)
>
&g
Actually, the second one is basically it. (Except that I don't know the Oracle
reference, so can't speak to that.)
Stu
> The first one is correct.
>
> On Tue, Sep 14, 2010 at 3:22 PM, peter veentjer wrote:
> I have got a question about the Clojure ensure and how it ac
The first one is correct.
On Tue, Sep 14, 2010 at 3:22 PM, peter veentjer wrote:
> I have got a question about the Clojure ensure and how it actually
> works and the documentation doesn't provide enough information.
>
> I see a few different solutions:
>
> 1) An optimist
I have got a question about the Clojure ensure and how it actually
works and the documentation doesn't provide enough information.
I see a few different solutions:
1) An optimistic approach: Once a ref is 'ensured' it is included in
the conflict detection set. This means that
Hi,
I have two refs a1, a2. One thread modifies a1, another modifies a2.
Sample code: http://gist.github.com/556679
If I don't ensure any ref in the transaction, the code runs in ~ 0.2
ms.
$ java -cp lib/clojure-1.2.0.jar\;src clojure.main -e "(require 'tt)
(tt/transaction-
On Mon, Mar 15, 2010 at 3:34 PM, Raoul Duke wrote:
> On Mon, Mar 15, 2010 at 1:13 AM, Christophe Grand
> wrote:
>> It hasn't blocked in the sense of "wait and continue": it retries the
>> transaction after growing the history of the ref (refs have an adaptive
>> history):
>
> i'm confused about
On Mon, Mar 15, 2010 at 1:13 AM, Christophe Grand wrote:
> It hasn't blocked in the sense of "wait and continue": it retries the
> transaction after growing the history of the ref (refs have an adaptive
> history):
i'm confused about being able to set :max-history, does that not run
the risk of b
hi Mark,
On Mon, Mar 15, 2010 at 2:16 AM, Mark Engelberg
wrote:
> Wow, the STM works far, far differently than I imagined, but I think I get
> it now. The adaptive history clarification helped tremendously. Thanks,
per chance, might you be willing/able to summarize the latest mental
model you
On 15 March 2010 08:44, Mark Engelberg wrote:
> Thanks Michal, those annotations helped quite a bit.
You're welcome!
> It also demonstrates
> to me that my mental model of how the STM works is quite out of touch with
> how it actually does.
I rather think I'm in that situation myself. Take the
On 15 March 2010 09:13, Christophe Grand wrote:
> It hasn't blocked in the sense of "wait and continue": it retries the
> transaction after growing the history of the ref (refs have an adaptive
> history):
Thanks a bunch for pointing this one out! I sort of recall reading
ref's docs and not reall
Wow, the STM works far, far differently than I imagined, but I think I get
it now. The adaptive history clarification helped tremendously. Thanks,
Mark
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@goo
ser/r
user=> (future (funk r))
#
1st read 1
user=> (dosync (ref-set r 5))
5
2nd read 1 ;; see, no retry
>From the end of (doc ref):
Normally refs accumulate history dynamically as needed to deal with
read demands. If you know in advance you will need history you can
set :min-history t
cing
a retry) of a transaction which only reads the ref.
If derefs really can force a retry, can't Meikel's example be rewritten
without ensure by just deref-ing again at the end?...
(dosync
(when (= @reactor-state :off)
(alter reactor-door open)
@reactor-state))
--
You received
2010/3/15 Mark Engelberg :
> Michal, aren't those examples backwards? I would expect the ensure version
> to be the one that needs to retry, and the deref version to be the one that
> doesn't.
Oh, I failed to notice this message, sorry... I've answered your reply
to Meik
On 15 March 2010 08:07, Mark Engelberg wrote:
> So what I'm finally realizing is that although you are guaranteed a
> consistent read value throughout the transaction, that value might become
> out of touch with "reality" unless you use ensure.
That's not true actua
2010/3/14 Meikel Brandmeyer
> In short: ensure is used when you require only read access to a Ref,
> but need the value to be constant through the transaction. If you
> modify the a Ref via alter or ref-set, the ensure is not necessary.
>
>
OK, I think I've finally figured
Michal, aren't those examples backwards? I would expect the ensure version
to be the one that needs to retry, and the deref version to be the one that
doesn't.
2010/3/14 Michał Marczyk
> On 15 March 2010 06:47, Mark Engelberg wrote:
> > What's a minimal example that
Hi,
On Mar 15, 6:47 am, Mark Engelberg wrote:
> What's a minimal example that demonstrates when ensure is necessary?
Ok. Maybe a little grotesque and not 100% valid, but it should get
across the idea.
(dosync
(when (= @reactor-state :off)
(alter reactor-door open)))
Once e
On 15 March 2010 06:47, Mark Engelberg wrote:
> What's a minimal example that demonstrates when ensure is necessary?
Here's a link to my posting to an earlier thread with a minimal
example of how ensure is different from deref:
http://groups.google.com/group/clojure/msg/8e477df
What's a minimal example that demonstrates when ensure is necessary?
--
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
e to the usage of "ensure". I couldn't figure
> out what exactly it does from its documentation string.
>
> Regards.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" gro
Hi,
Can anybody give an example to the usage of "ensure". I couldn't figure
out what exactly it does from its documentation string.
Regards.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clo
On Thu, Sep 17, 2009 at 1:09 PM, John Harrop wrote:
> Don't commutes commute with one another, but not with other writes?
That's certainly correct from the standpoint of thinking about how
commutes get reexecuted during the commit and other writes (from
ref-set and alter) do not.
Here is how I
Don't commutes commute with one another, but not with other writes?
--~--~-~--~~~---~--~~
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 ne
ansactions cannot write the same Ref without some of them
> having to retry. If you use commute instead of ref-set or alter then
> they don't have to retry.
But lets be careful here. (commute identity foo) does not
help when you need (ensure foo), that is the latter can
guard against
On Thu, Sep 17, 2009 at 11:12 AM, John Harrop wrote:
> On Thu, Sep 17, 2009 at 11:04 AM, Mark Volkmann
> wrote:
>>
>> On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
>> >
>> > On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>> >>
>> >
On Thu, Sep 17, 2009 at 11:04 AM, Mark Volkmann
wrote:
> On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
> >
> > On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
> >>
> >> Final question. The docs say that 'ensure' permits more concurrency
> >>
On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>
> Final question. The docs say that 'ensure' permits more concurrency
> than promoting the ref to a write. Is there a quick/simple way of
> explaining how? (Or do I need to go to the source :-)
If you have multiple transact
On Thu, Sep 17, 2009 at 9:57 AM, Chouser wrote:
>
> On Thu, Sep 17, 2009 at 12:28 AM, Krukow wrote:
>>
>> Final question. The docs say that 'ensure' permits more concurrency
>> than promoting the ref to a write. Is there a quick/simple way of
>> explainin
On Wed, Sep 16, 2009 at 11:28 PM, Krukow wrote:
>
> Final question. The docs say that 'ensure' permits more concurrency
> than promoting the ref to a write. Is there a quick/simple way of
> explaining how? (Or do I need to go to the source :-)
When you call ensure
ency in
> the use-case I mentioned in this post. In my example I have two
> accounts a1 and a2, requiring that @a1 + @a2 >= 0 invariably. A
> withdraw transaction that ensures one account, checks that the
> invariant holds, and does the withdrawal from the other is really
> per
e
invariant holds, and does the withdrawal from the other is really
permitting less concurrency than what is optimal. The call to ensure
prevents/serializes also any concurrent activity which would not
violate the constraint that @a1 + @a2 >= 0, e.g., a concurrent
deposit.
So it seems that multi-
On Sep 16, 11:39 am, Stuart Halloway
wrote:
> The docs could be more clear, but if validate-fn must be side effect
> free then it certainly can't look at any other refs.
>
Yes. The docs should say the function must be pure. While I understand
the multi-ref validation use case, currently it i
The docs could be more clear, but if validate-fn must be side effect
free then it certainly can't look at any other refs.
Stu
> On Sep 16, 11:15 am, Christophe Grand wrote:
>> I think you managed to produce a deadlock :-(
>>
>> thread 1 is commiting and has a write lock on a1
>> thread 2 is c
On Sep 16, 11:15 am, Christophe Grand wrote:
> I think you managed to produce a deadlock :-(
>
> thread 1 is commiting and has a write lock on a1
> thread 2 is commiting and has a write lock on a2
> thread1 tries to acquire a read lock on a2 (in the validator) and blocks
> because thread2 has a
On Wed, Sep 16, 2009 at 6:34 AM, Krukow wrote:
> Another interesting thing happened. I wrote another program using ref
> validators only.
>
> http://paste.lisp.org/display/87117#4
>
> That program does produce write-skews. Further, occasionally the
> program never terminates! I did (run 100) a fe
On Wed, Sep 16, 2009 at 6:13 AM, Krukow wrote:
> On Sep 15, 10:23 pm, Mark Volkmann wrote:
> > I think the problem is that you only ensure one of the Refs. If you
> > want to make sure that a condition between multiple Refs isn't
> > violated, you need to sure al
a fairly recent, but not the latest version of Clojure.
I've upgraded to the latest from Git, and I now get the same output as
you: I am unable to produce a write-skew in program 2, the "ensure
version".
Another interesting thing happened. I wrote another program using ref
validators
On Sep 15, 10:23 pm, Mark Volkmann wrote:
> I think the problem is that you only ensure one of the Refs. If you
> want to make sure that a condition between multiple Refs isn't
> violated, you need to sure all of them. Otherwise other transactions
> will be free to modify the
maly, I wanted to
> write a program exhibiting the anomaly, together with a similar
> program using ensure to eliminate it.
>
> My program doesn't work: it exhibits the anomaly, but ensure doesn't
> fix it, and neither does adding a validator to the refs. I'd like t
On Tue, Sep 15, 2009 at 3:23 PM, Mark Volkmann
wrote:
> I think the problem is that you only ensure one of the Refs. If you
> want to make sure that a condition between multiple Refs isn't
> violated, you need to sure
I meant "ensure" instead of "sure"
I think the problem is that you only ensure one of the Refs. If you
want to make sure that a condition between multiple Refs isn't
violated, you need to sure all of them. Otherwise other transactions
will be free to modify the Refs that aren't ensured.
On Tue, Sep 15, 2009 at 3:14
After a discussion in dcug about the write-skew anomaly, I wanted to
write a program exhibiting the anomaly, together with a similar
program using ensure to eliminate it.
My program doesn't work: it exhibits the anomaly, but ensure doesn't
fix it, and neither does adding a validator t
e gotten a new committed value
after the current transaction try began given that the current
transaction successfully called ensure on the Ref. Maybe the answer is
that the order of events was as follows:
1) Transaction A starts.
2) Transaction B starts.
3) Transaction B changes Ref R.
4) Transaction
On Feb 11, 10:55 am, Jeffrey Straszheim
wrote:
> So, ensure can make you rollback if the value is not current when you
> commit. Can it make other transactions rollback if you've ensured a ref,
> and commit before them?
>
No. That's what I meant to imply by (b). ensure
So, ensure can make you rollback if the value is not current when you
commit. Can it make other transactions rollback if you've ensured a ref,
and commit before them?
On Wed, Feb 11, 2009 at 7:52 AM, Rich Hickey wrote:
>
>
>
> On Feb 10, 10:26 pm, Jeffrey Straszheim
> wr
On Feb 10, 10:26 pm, Jeffrey Straszheim
wrote:
> Since we're on the subject, what exactly does ensure *do* that simply
> reading the ref does not? And then, how does it differ from writing.
>
If you merely read a ref in a transaction that won't prevent another
transacti
>
>
> Why can't I use ensure inside of a dosync block? Is there another way to
>> perform a transaction?
>>
>
> You can, but "map" is lazy. It's not being evaluated within the dosync. One
> way to fix the code is to force map to evaluate wit
the
> > reader outside of the dosync.
> >
> > Now what I don't understand is why, when I run:
> >
> > (dosync (dorun (map ensure [account1])))
> >
> > I get:
> >
> > java.lang.RuntimeException: java.lang.IllegalArgumentException
On Feb 10, 10:24 pm, Jeffrey Straszheim
wrote:
> Say hello to laziness.
>
> Your code is returning a lazy seq (from the map), which is evaluated by the
> reader outside of the dosync.
>
> Now what I don't understand is why, when I run:
>
> (dosync (dorun (map e
Since we're on the subject, what exactly does ensure *do* that simply
reading the ref does not? And then, how does it differ from writing.
On Tue, Feb 10, 2009 at 10:24 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:
> Say hello to laziness.
>
> Your code is
Say hello to laziness.
Your code is returning a lazy seq (from the map), which is evaluated by the
reader outside of the dosync.
Now what I don't understand is why, when I run:
(dosync (dorun (map ensure [account1])))
I get:
java.lang.RuntimeException: java.lang.IllegalArgumentExce
On Feb 10, 2009, at 10:01 PM, Eric Lavigne wrote:
Why can't I use ensure inside of a dosync block? Is there another
way to perform a transaction?
You can, but "map" is lazy. It's not being evaluated within the
dosync. One way to fix the code is to force map to evaluate
The way I understand it, "transaction running" means that the code is
executing inside a dosync block. So this should work:
(def account1 (ref 1000))
(def account2 (ref 2000))
(dosync (map ensure [account1 account2]))
However, I get the following error:
java.lang.IllegalStateExc
On Dec 17, 2008, at 2:31 PM, Chouser wrote:
On Wed, Dec 17, 2008 at 2:10 PM, Randall R Schulz
wrote:
Since Chouser asked on #clojure which REPL (I was using the Contrib
REPL), I tried this with the stock REPL and the hang does not occur.
Specifically, this line causes the JVM to shut do
On Wed, Dec 17, 2008 at 2:10 PM, Randall R Schulz wrote:
>
> Since Chouser asked on #clojure which REPL (I was using the Contrib
> REPL), I tried this with the stock REPL and the hang does not occur.
Specifically, this line causes the JVM to shut down, even if there are
agent threads in their po
On Wednesday 17 December 2008 10:57, Randall R Schulz wrote:
> On Monday 15 December 2008 17:58, Randall R Schulz wrote:
> > ...
>
> This sequence of evaluations ends in the REPL hanging:
>
> 1:1 user=> (.. Runtime (getRuntime) (addShutdownHook (new Thread
> shutdown-agents))) nil
> 1:2 user=> (de
(with
> > zero CPU usage). As Rich pointed out to me, this is avoided by
> > calling (shutdown-agents).
>
> > So my question is this: What's a simple way to ensure that
> > (shutdown-agents) is called when necessary without having to remember
> > to manually e
by
> calling (shutdown-agents).
>
> So my question is this: What's a simple way to ensure that
> (shutdown-agents) is called when necessary without having to remember
> to manually enter that call at the REPL before exiting?
This sequence of evaluations ends in the
On Tuesday 16 December 2008 07:36, Randall R Schulz wrote:
> ...
>
> So I am still confused about the right way to deal with agents in
> order to get reliable and prompt exit from the REPL and why an EOF
> from the terminal hangs (only if agents were started and regardless
> of whether a shutdown
On Tuesday 16 December 2008 06:02, MikeM wrote:
> You can try this:
>
> (let [t (new Thread (fn[] (shutdown-agents)))]
>(.. java.lang.Runtime (getRuntime) (addShutdownHook t)))
>
> It works for me, but seems to take a long time to complete the
> shutdown.
I tried adding this to the module tha
You can try this:
(let [t (new Thread (fn[] (shutdown-agents)))]
(.. java.lang.Runtime (getRuntime) (addShutdownHook t)))
It works for me, but seems to take a long time to complete the
shutdown.
Your question made me wonder if the agent thread pools should use
daemon threads - then this woul
Hi,
I've just started using agents and as I've done that, I've noticed that
once you use an agent, exiting the REPL leads to a hang (with zero CPU
usage). As Rich pointed out to me, this is avoided by calling
(shutdown-agents).
So my question is this: What's a simpl
On Oct 14, 10:33 pm, Tom Davies <[EMAIL PROTECTED]> wrote:
> In relational database terms, Clojure's STM has 'read-committed'
> isolation when you don't use 'ensure', then?
No, it's snapshot isolation, which is distinct from all of the
traditional
In relational database terms, Clojure's STM has 'read-committed'
isolation when you don't use 'ensure', then?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" gro
ammer to
ensure that all refs that need to be invariant, are.
Thanks,
Jim
--~--~-~--~~~---~--~~
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
To unsubs
On Oct 13, 9:51 pm, jim <[EMAIL PROTECTED]> wrote:
> Rich,
>
> I've been working with refs tonight and I appreciate the validate-fn
> addition. Makes my life a lot easier.
>
> From reading the docs, 'ensure' keeps a ref from changing inside a
> dosync.
Rich,
I've been working with refs tonight and I appreciate the validate-fn
addition. Makes my life a lot easier.
>From reading the docs, 'ensure' keeps a ref from changing inside a
dosync. But if accesses to refs are contained in function calls that
are called during th
94 matches
Mail list logo
