Clojurians Log v2
core-async
So I’ve implemented a bounded core async set buffer with an atom and a set, and it seems to work as I’d like:
My question is it seems core.async, checks channels test full? before putting into the channel… However a few things have occured to me…
1. there’s a difference between the time you check full? and the time you put! into the channel… I’m assuming this isn’t a problem however because of the mutex inside the channels.
2. Given that there’s a mutex inside the channel, do I need to even use my atom here? Could I not get away with using a plain old java set instead?
the built in buffers just use plain data structures
you are protected by the mutex lock
Yes that’s what I’d noticed though they’re all java.util.LinkedLists and I’d assumed they were getting away with using that because LinkedList’s are effectively persistent data structures anyway… Though I see that actually j.u.LinkedList is a double linked list, and not thread safe.
it's not thread safe
but the idea is that buffer manipulation is protected by the channel lock
yeah, this does mean in order to exert the backpressure via a 503 without blocking my request I need to also acquire that mutex with a try finally over (.. the-chan mutex lock)
You shouldn't need to touch the lock or the buffer directly
offer the value to the channel, and if it doesn't take it report the 503
Your buffer is unordered so you are losing the fifo queue behavior channels typically have
You also wipe the buffer on close, which none of the built in buffers do, which means, I think, you won't be able to consume items that were inserted before the channel was closed
oh yes thanks for reminding me about offer! I’d forgotten I discovered that yesterday :thumbsup:
Yes I know. I don’t really require ordering, though I’ll maybe swap it to use a LinkedHashSet to save anyone else using it any confusion.
ahh thanks for clarifying, I wasn’t sure what the behaviour should be there; but makes a lot of sense