## What I believe should be right:

** case 1:

  (>! on-closed-channel val) ==> exception thrown

or

** case 2:

  (>! open-channel val) ==> returns val

  (>! closed-channel val) ==> returns nil


## race condition:

  note: I do not consider the following to be a valid "solution"

  (if (open? chan)
    (>! chan ...)) ;; race condition prone


## What I consider to be wrong

I understand why <! on a closed channel returns nil.

I don't understand why >! on a closed channel return nil.

For <!, on the receiver, I can distinguish "got msg" from "channel is
closed" since one gives me a message, and the other returns nil.


For >!, on the sender, I can NOT distinguish "send msg" from "channel is
closed."


Thus, for >! on a sync-channel, it is:

  well, either the channel is open, and we sent it OR the channel is
closed, and we'll silently drop


Also, for >!! on a buffered-channel, it is:

  well, if it's not full, we'll send it, if it's full, we'll park OR if the
channel is closed, we'll pretend the channel was not full and silently drop


Now, here is the thing I don't understand -- why are core.async semantics
defined as such? And is there anyway I can get around this? (It's not clear
I can solve this problem by re-interpreting at either the channel or the
buffer layer).

## Question:

core.async is designed by people far smarter than me. Yet, I can't get this
case to work. What am I doing wrong?

Thanks!

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to