Fs2: `InspectableQueue` losing writes?

[kubukoz]

As mentioned in the gitter channel, I've encountered some strange behavior with InspectableQueue.

Running this program:

val sizeLimit = 5 //or something similarly small - it's harder to reach the problem as this number grows to hundreds
val program = for {
  q <- InspectableQueue.bounded[IO, Unit](sizeLimit)

  //note: the same happens with `offer1`
  job = (jobId: Int) => q.enqueue1(()) *> putStrLn[IO](show"$jobId: offered to queue")

  //enqueue elements concurrently - this should eventually make the queue full
  _ <- (1 to sizeLimit).toList.parTraverse_(job).start

  //show the latest queue's size after changes
  _ <- q.size.discrete.evalMap(size => putStrLn[IO](show"queue size: $size")).compile.drain.start

  //terminate the program when the queue is full
  _ <- q.full.discrete.takeWhile(!_).compile.drain
} yield ()

should result in termination within at most a couple of seconds - the condition of termination is the queue being full, and while waiting for that to happen we enqueue N (N being the queue's size limit) elements to it.

Sometimes it works, but about as often it just hangs - but the "offered to queue" string is always displayed for every enqueue that we want to make happen. In the case the program hangs, the discrete stream of the queue's size never reaches the size limit, and the queue is never full.

A typical output in the case of hanging is:

3: offered to queue
4: offered to queue
1: offered to queue
2: offered to queue
5: offered to queue
queue size: 4

The elements also don't seem to be properly enqueued if the queue is unbounded. Of course then we can forget about the full state, but the size is impacted.

Here's a repo/branch with a full reproducible: https://github.com/kubukoz/fs2-playground/tree/hanging-queue

Checked on fs2-core v1.0.0-M5

[SystemFw]

I'll try to have a look at this, but a bit busy right now. I guess the first step would be to check if this is a regression, and works on previous versions.

@kubukoz what version are you on?

[kubukoz]

1.0.0-M5, adding to issue description. I can check on the latest 0.10.

[pchlupacek]

@SystemFw would be interesting to test in on current 1.0 master with QueueStrategy. I think it will be much easier to reason about it. I think this seems like race condition, and I think the Inspectable queue, may have been subject to it.
@kubukoz can you try to test with M3/M4 before Inspectable queue has been introduced? Essentially verify that former queue implementation was correct.

t/y

[kubukoz]

M3/M4 are affected, 0.10.6 worked fine, and current series/1.0 is also OK after the adjustments related to full being gone - I guess we could close this

[SystemFw]

I'd keep it open until an RC build is out, for visibility