Re: core.async/close! locks on chans with pending transforms

2017-07-04 Thread Vitalie Spinu
>> On Mon, Jul 03 2017 21:18, Timothy Baldridge wrote: > This means, if you want to execute take correctly you must ensure that only > one thread executes the take instance at one time, since channels already > operate via a channel-level lock, it makes sense to run the transducer > inside the ch

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Timothy Baldridge
A big reason they have to be run inside the lock is that they have to operate in the context of the channel. For example: (chan (take 10)) Firstly we must recognize that transducer instances are *not* thread safe. They should only ever be executed by one thread at a time. But channels allow mult

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Kevin Downey
On 07/03/2017 03:12 PM, Vitalie Spinu wrote: On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote: Discussion of locks aside, doing blocking operations like io or !! or basically anything that looks like it blocks and isn't >! or Is this the limitation in general or only whe

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Vitalie Spinu
On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote: > > > Discussion of locks aside, doing blocking operations like io or >!! or basically anything that looks like it blocks and isn't >! or is a very bad idea in a transducer on a channel. You will (eventually) > block the threadpo

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Vitalie Spinu
> the side-effect of this means that no other operation (puts, takes or closes) Is there a deeper reason for this beside the ease of implementation? If chan is buffered I still fail to see why should close and take block. -- You received this message because you are subscribed to the Googl

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Kevin Downey
On 07/03/2017 11:03 AM, Vitalie Spinu wrote: Hi, Async/close! causes deadlocks if its reducer is stalled (e.g. waits for an event from another chan). Consider: (let [d (chan) s (chan 1 (map (fn [v] (println "this:" v) (printl

Re: core.async/close! locks on chans with pending transforms

2017-07-03 Thread Timothy Baldridge
Transducers on channels lock the channel while they are running. This is by design. So yes, the side-effect of this means that no other operation (puts, takes or closes) can succeed while the transducer is running. So the short answer is: If you have code that can take awhile to run, don't put it

core.async/close! locks on chans with pending transforms

2017-07-03 Thread Vitalie Spinu
Hi, Async/close! causes deadlocks if its reducer is stalled (e.g. waits for an event from another chan). Consider: (let [d (chan) s (chan 1 (map (fn [v] (println "this:" v) (println "from d:" (! s 1)) (Thread/sleep 100) (pri