Is it possible to write a reducing function that mutates a list in Clojure?
Sure. But I think it is absurdly unlikely that it would happen by accident.
 My 1% chance wasn't hedging against that case -- I was hedging against a
bug in reduce itself.

I don't really see even a 1% likelihood of either of those, but I played
D&D as a kid and learned that even the most unlikely things happen one time
in twenty. :-)

Stu


On Tue, Dec 11, 2012 at 3:30 PM, Marko Topolnik <marko.topol...@gmail.com>wrote:

> Just curious, how did you immediately eliminate the possibility that the
> reducing function was mutating the list that is being reduced? No
> concurrency involved. In regular Java the 95% leading cause of CME is
> precisely that.
>
> Anyway, this applies to immutable structures per se, whether combined with
> atoms, refs, or none. But a full wartime story must also cover how the
> solution avoids the pitfalls of retryable transactions. This is the real
> sore point in my experience, and the one which makes STM an all-or-nothing
> enterprise.
>
>
> On Tuesday, December 11, 2012 8:53:40 PM UTC+1, stuart....@gmail.comwrote:
>>
>> Hi Paul,
>>
>> Here is a real-world, production software example of the advantage of
>> values+refs over mutable objects and locks. A Datomic user reported the
>> following stack trace as a potential bug:
>>
>> 12:45:43.480 [qtp517338136-84] WARN  c.v.a.s.p.e.UnknownExceptionH**andler
>> - UnknownExceptionHandler: null
>> java.util.ConcurrentModificati**onException: null
>>        at 
>> java.util.ArrayList$Itr.checkF**orComodification(ArrayList.**java:819)
>> ~[na:1.7.0_07]
>>        at java.util.ArrayList$Itr.next(A**rrayList.java:791)
>> ~[na:1.7.0_07]
>>        at clojure.core.protocols$fn_**_5871.invoke(protocols.clj:76)
>> ~[clojure-1.4.0.jar:na]
>>        at 
>> clojure.core.protocols$fn_**_5828$G__5823__5841.invoke(pro**tocols.clj:13)
>> ~[clojure-1.4.0.jar:na]
>>        at clojure.core$reduce.invoke(cor**e.clj:6030)
>> ~[clojure-1.4.0.jar:na]
>>
>> I immediately had 99% confidence that the bug was in user code, and even
>> a pretty good idea what went wrong.  A call to "reduce" is a functional
>> transformation, and it expects to be passed values.  The exception clearly
>> indicates a violation of that contract, and is caused by cross-thread
>> aliasing and mutation in the calling code.
>>
>> Regards,
>> Stu
>>
>  --
> 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 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

Reply via email to