TBQueue of size 0 doesn't work as expected

[infinity0]

If you have a TBQueue of size 2, you can put 3 times on it, then the 3rd call will block until you read from the queue (from another thread).

If you have a TBQueue of size 1, you can put 2 times on it, then the 2nd call will block until you read from the queue (from another thread):

Control.Concurrent.STM.TBQueue> q <- newTBQueueIO 1 :: IO (TBQueue ())
Control.Concurrent.STM.TBQueue> a <- async $ (atomically $ writeTBQueue q ()) >> print "wrote"
"wrote"
Control.Concurrent.STM.TBQueue> a <- async $ (atomically $ writeTBQueue q ()) >> print "wrote"
Control.Concurrent.STM.TBQueue> atomically $ readTBQueue q
"wrote"
Control.Concurrent.STM.TBQueue>

Therefore, if you have a TBQueue of size 0, you'd expect that you can put 1 time on it, then the 1st call will block until you read from the queue (from another thread). However this doesn't work:

Control.Concurrent.STM.TBQueue> q <- newTBQueueIO 0 :: IO (TBQueue ())
Control.Concurrent.STM.TBQueue> a <- async $ (atomically $ writeTBQueue q ()) >> print "wrote"
Control.Concurrent.STM.TBQueue> atomically $ readTBQueue q
--- hangs forever

[ChristopherKing42]

The rule is that readTBQueue blocks until there is something in the queue, which it is doing in the above snippets. The pattern you noticed is a coincidence.

[infinity0]

Generally when you notice a pattern, you should think harder before calling it a coincidence. :)

A blocking queue of capacity 0 that works as I described is a well-known concept in this type of programming, rust supports it in a general way, java supports it in a specific way, kotlin supports it in a general way.

[gbaz]

The ticket is named poorly. This is not a bug. It is a feature request for a different semantics, which corresponds to a different set of expectations. There's arguments for various "expected" semantics, but putting on the level of which is "correct" as opposed to "both desirable and straightforward to implement" is a recipe for a bad discussion.

[infinity0]

Why would you consider other people claiming the current behavior is "incorrect" as a "recipe for bad discussion"? Generally, bugs exist, and people have different opinions on things including what things are bugs.

Two languages I mentioned implement the behaviour in the same general data structure (capacity = 0 or more); java implements it in a special data structure and throws IllegalArgumentException when you try to instantiate the general data structure with capacity = 0.

I'm not even sure what use is the current Haskell behaviour for capacity = 0, you can neither read nor write from it, they both block indefinitely!

[ChristopherKing42]

The semantics in Haskell is that writes block when the queue is at capacity and reads block when the queue is empty. It sounds like to do what you want you'd use a capacity 1 queue instead. No need to change how the 0 capacity queue works.

[infinity0]

No, capacity 1 doesn't work - the difference is as I described in my first post. There is a cross-language common convention for the behaviour here.

[gbaz]

@infinity0 getting correct and performant stm structures is a bit tricky. If you wanted to write a patch that preserved existing characteristics and behavior in every case but the 0 case, I'm sure it would be well received. But insisting that a feature request is really about "expected behavior" won't win you any friends among maintainers.

[gbaz]

That said, its easy enough to handle this special case behavior (if its ever desired, and its not clear to my why it would be especially useful) by wrapping an MVar containing a Maybe value.

[ChristopherKing42]

@infinity0 wait, you want the read and the write to happen at the same time? That simply isn't possible in STM due to its ACID guarantees (specifically isolation).

[gbaz]

Christopher as I understand it the desired semantics is the write blocks until a read. That's doable. I just don't see why.

[ChristopherKing42]

@gbaz is it? If the write retries, the read wouldn't see the write, correct? You'd need to split the write into two transactions, one to write, and the other to block, correct?

[gbaz]

Just create an mvar with Nothing. Writes of Just a to it block. The read atomically checks if the mvar is nothing, and if so takes it, then recurs, and if it is Just a then swaps it for a Nothing and returns. I think that works.

[ChristopherKing42]

@gbaz doesn't retry make the transaction rollback all the changes it made? TMVar calls retry when it blocks.

[gbaz]

Good point. What I described gives you a TBQueue that works but not one that works atomically. Since the fundamental unit of stm is a TMVar, which is a 1 element TBQueue, conceptually, this is rather tricky to overcome.

[gbaz]

Wait, nevermind, what I described is reasonable. Sure retry will roll the changes back, but then, conceptually, it'll do them again, until it succeeds. The external effect is a block. That's how stm works. Witness the description of observed behavior (which has "blocking") in the original post.

Anyway, it seems feasible, if genuinely desired, as a one-off. But I don't understand the use-case.