Java memory model & stateful tranducers

Hi ! I'm a bit confused about the official design rules for stateful transducers and transducing contexts, especially about which one should be in charge of memory visibility guarantees. The common practice seems to be using volatiles to hold state in transducers (e.g distinct

Re: Java memory model & stateful tranducers

nnel itself properly locks to make that state visible. That >> said, it does seem odd to me now that partition-by and partition-all have >> state that is not volatile. Thinking about it. >> >> On Wednesday, December 7, 2016 at 11:39:54 AM UTC-6, Léo Noel wrote: >

Re: Using transducers in a new transducing context

This topic is of high interest to me as it is at the core of my current works. I had a similar questioning a while ago and I have to say I'm even more confused with this : While transducing processes may provide locking to cover the

Re: Using transducers in a new transducing context

> > What you said holds for reduction but not necessarily a parallel fold (see > clojure.core.reducers/fold). > Exactly, and that's why stateful transducers are explicitly forbidden in fold and in core.async pipeline functions. This is not related to memory visibility, this is due to the fact t

Re: Using transducers in a new transducing context

Thank you Alex for these precisions. The JVM is pretty good at minimizing this stuff - so while you are stating > these barriers are redundant and are implying that's an issue, it would not > surprise me if the JVM is able to reduce or eliminate the impacts of that. > At the very least, it's t

Re: Using transducers in a new transducing context

a time rule is implemented by the transducing > context (transduce, into, core.async, etc). Inside of a transducer's > implementation you just have to make the assumption that it's being > used properly. volatile! is what ensures that there's a memory > barrier

Re: Using transducers in a new transducing context

> > I could have one thread that invokes a transduce step on odd seconds and > another that invokes on even seconds. Or some external api call that tells > me to take the next step, which I do on a thread pulled from a pool. > Both strategies will fail to ensure no more than one thread at time.

Re: Using transducers in a new transducing context

ng is optimizers' responsibility. On Wednesday, April 12, 2017 at 5:34:32 PM UTC+2, Seth Verrinder wrote: > > Reordering definitely matters: > > StepA: write to x > StepB: read from x > > StepB: read from x > StepA: write to x > > On Wednesday, April 12, 2017 at 7:15:09

[ANN] task a.1

Hi fellow clojurians, I just released the first alpha of task : https://github.com/leonoel/task Task is a specification and toolkit to define and compose generic computations in clojure. I would appreciate any feedback on this project, be it about definitions, design, or even on the relevance of

Re: [ANN] task a.1

h the development and plan to give it a whirl on a hobby project. > > Thanks Léo! > > On Fri, Nov 10, 2017 at 11:35 AM, Léo Noel wrote: > >> Hi fellow clojurians, >> >> I just released the first alpha of task : https://github.com/leonoel/task >> Task is a s

Re: Why does the `def-` not exist?

My opinionated 2 cents : I think the whole visibility feature was a mistake, it doesn't provide any value and it should be taken away from the compiler (I guess it would not break anything to ignore :private metadata and make every var public). Every single time I asked myself whether I needed

Re: Why does the `def-` not exist?

Or maybe people are confused because the :private metadata *complects* two separate concerns : *API commitment* and *visibility*. If there was a way to programmatically make the distinction between implementation and API without impacting visibility, it would be tremendously valuable for tooling

Re: Why does the `def-` not exist?

olproof Léo, but sometimes folks use docstrings to make that > distinction i.e. if it's got a docstring it's part of the public API. > Codox, for example, takes this approach when deciding what to include in > generated API documentation. > > On 4 March 2018 at 12:50, L

[ANN] missionary a.1

Missionary is an asynchronous programming toolkit for clojure and clojurescript. https://github.com/leonoel/missionary Features include non-blocking synchronization primitives, coroutine syntax for sequential logic, parallel composition operators and timing helpers. Missionary relies on the task