>
> This brings up another issue: Currently writing to a closed channel is a
> no-op, but it probably should throw an exception. Similarly, closing a
> closed channel is a no-op, but also probably should throw an exception.
> Both are things that a well behaved sender should never do, since th
>> You're only supposed to close a channel from the producer side.
> Why?
First, an appeal to authority: http://golang.org/pkg/builtin/#close
Notice the type of the argument: chan<-
That's a write-only port. Go's type system allows automatic coercion from
read/write ports to constrained read or wr
>
> Querying the state of a channel at worst leads to race conditions and at
> best leads to bad design.
>
The open/closed state of a channel is simple to reason about (it only
changes, if ever, once), unlike the rest of state that is associated to a
given channel...
You're only supposed to close
> However, if what one is trying is to *stop* putting values on the
channel, I see no possible race conditions.
Querying the state of a channel at worst leads to race conditions and at
best leads to bad design.
You're only supposed to close a channel from the producer side. So if
you're the on
If one used those preds to try putting values on the channels one is asking
about, then yes, that would generate a classic nasty check-then-act
scenario:
(when-not (closed? c) (>! c 42)) ;; Value could be never put, in face of
interleavings
Programmers experienced in concurrency should have de
On 12 July 2013 01:08, Michał Marczyk wrote:
> (Actually this is simplified a bit in that it's also single consumer,
> but that's not a feature of the approach, but rather my quick & dirty
> poc.)
Single consumer, multiple producers:
https://gist.github.com/michalmarczyk/5980700
--
--
You rec
Wouldn't closed and drained predicates introduce race conditions?
(Sorry for brevity, on my phone)
--
--
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
As for the producer/consumer scheme with the higher-order channel, it
works in the single-producer case:
https://gist.github.com/michalmarczyk/5980097
(Actually this is simplified a bit in that it's also single consumer,
but that's not a feature of the approach, but rather my quick & dirty
poc.)
Hi Timothy,
That's very cool and very good to know!
Cheers,
M.
On 12 July 2013 00:56, Timothy Baldridge wrote:
> It's interesting to note that blocking go blocks can actually be GC'd. For
> example, run this in a repl:
>
> (loop [] (let [c (chan)]
> (go (>! c 42)))
> (recur))
>
It's interesting to note that blocking go blocks can actually be GC'd. For
example, run this in a repl:
(loop [] (let [c (chan)]
(go (>! c 42)))
(recur))
On my box the CPU and memory spikes, but after I CTRL+C and kill the loop,
the GC kicks in and collects all the channels and gos
I think you could pass the producer a higher-order (chan 1) with the
actual communication channel placed in the buffer.
Then at each step the producer would do
(when-let [c (! c (rand))
(>! communication-channel c))
Once you close communication-channel, the put succeeds, but then the
take on c
I haven't been in any discussions about this with the team, so it's
entirely possible I am ignorant of some established future direction... but
- "closed?" seems useful to me. (It may also be useful to ask "drained?"
(closed + empty).)
- >! returning an indicator of success also seems useful. Ho
Consider a happy, oblivious producer of values:
(def c (chan 42))
(go (while true (>! c (rand
It doesn't know where/now the channel is consumed (which part of the point
of channels/queues). However, we *do* know that at some point, nobody will
need the result of our producing, so we should
13 matches
Mail list logo
