what's strange is that it works about 1/2 of the time

Thanks for taking a look, @tbaldridge I get very inconsistent results. Like, just now:

:b read true
:b read true

:b read :to-write
:a read :to-write

For you it works sometimes even?

That true looks like it should never end up there ...

yeah, I'm really sure there's a bug here somewhere

what's really odd is that it happens with thread and alt!! as well

no clue why

Also happens when giving c a buffer

@tbaldridge maybe there's a bug in do-alt then?

ah wait

does >! return true?

Yes

Unless the channel is closed.

no nvm

yeah, I think the issue is related to this: "Each option may appear at most once. The choice and parking characteristics are those of alts!"

notice how nothing ever writes. This is because we're using the same channel twice, and I think the macro is doing some sort of indexing or grouping based on the channel

and the code is being mixed up with a different op

mhh I read that "each option may appear at most once" as (alt! c 43 c 42) not being allowed, not not allowing either a take or a put to the same channel

but maybe you're right

same here, but the behavior fits

wonder what appens if we (let [w c]

nothing

watch what happens if you increase the "dotimes [x 2]" to 4 😉

heh

in one of my tests it printed 4 log messages

Yeah. Did that, too.

that with go or thread?

i only get 2 and wait with thread

I get more if I increase the buffer of log accordingly.

Each option may appear at most once. is only stated in regards to alt!. I guess I could try alts! then, even though that wouldn't look as nice.

But I do need to say this...this is some wacky code. Writing and reading to the same channel from the same thread isn't a pattern that happens in production code.

True.

I was trying to port the go-lang chatroulette example to Clojure: https://engineering.tumblr.com/post/23049359840/talk-by-andrew-gerrand-go-code-that-grows-with (about minute 19 in the video)

He uses that in there to match connections.

By the way, no luck using alts!. Same wacky inconsistent behavior.

heh, I just realized something....I haven't a clue how this works with the implementation of channels....

yeah

i'm looking at the macroexpansion of alt!

it 100% gets confused if you take and write to the same channel

boils down to (let [c (chan)] (alts!! [c [c :w]]))

Since alts! shows the same behavior it must go deeper than the alt! macro.

I think it might be at the channel level

that sometimes returns true, sometimes return :w

So here's how a channel works: If you put, the op locks the put handler and the channel. Then it looks for a take, if it finds a take it locks the take handler, then it commits the put and the take, and dispatches the values through the put and take handlers.

In an alt! all the branches share the same handler. So in that case the put and the take hander are the same handler. But all the semantics of the handler are commit/deliver once.

very weird edge case

You have no idea how excited that makes me feel. I'm such a fanboy.

Well you stumped me and bronsa, so (thumbsup) for that one 🙂

It'll probably be awhile before I hear back from Rich, and I'm 90% sure the answer is "don't do that", but I'm interested in hearing if he agrees with my theory

I must admit that it looked like a clever bit of code in the go-lang example. Now I have to come up with a different way to do the connection pairing 🙂

Yeah go seems fond of that sort of stuff for some reason

Apparently writing to a channel then reading from that same channel is a pattern in go-lang

Um... sounds like let

A complicated let

Nice detective work!