Fabio Labella

It does work for me, but _perhaps_ we should make it a bit easier for other people to grab the old implementation if they stumble upon this

I think the latest commit with the old implementation is this one https://github.com/typelevel/fs2/blob/4ddd75a2dc032b7604dc1205c86d7d6adc993859/core/shared/src/main/scala/fs2/concurrent/Topic.scala Which should be mostly source compatible. Are you hitting a problem because of Topic under load?

FYI in fs2 3.0 we have reinstated the implementation strategy of the old version of Topic

@djspiewak it races an additional F to implement interruption of eval nodes (which btw is broken right now), i'm not entirely sure that's the problem here though? in particular that...

Have we measured this to make a difference?

Personally I'm a bit skeptical of reasoning about performance this way, we've had several cases where code that _ought_ to be slower ended up being faster, including in Channel itself...

I'm working on a general solution to this problem. Can't promise it's going to work yet, but let's see where it goes.

> Which means that poll() was executed twice Is that unavoidably the case, or could it be that `poll` and `commit` are executing concurrently?

> Either way that means the control flow has broke. I'm not sure you can draw that conclusion. `groupWithin` is inherently a concurrent operation. Note that in the kafka library...

> you mean that groupWithin will keep buffering while the downstream is processing - that would also mean that groupWithin does not backpressure, No, it's not quite like that. What...