Richard Schneeman

Some high level thoughts: I think we might want to consider what shape this problem would look like as a rack standard. Would we ever care to formalize this interface...

> It buys you quite a lot. If you have an app that is generally speaking farily average but has a couple super IO heavy endpoints, it allows you to...

> I'm proposing a very specific implementation though. Okay don’t stays on the same thread. And puma forgets about it, so it will spawn a new one eventually to replace...

Short: I think i understand the proposal intent a bit better now, thanks for the extra explanation. Now that I understand the constraints a bit better, what if we had...

> I don't see what it gains you I'm still worried about thread exhaustion. I don't like secret magic limits inside my apps. The previous "fast pipeline" behavior was the...

> Is this an issue for the Ruby bug tracker as well? @p8 yes, eventually. Ideally I want to get a smaller [reproduction](https://www.codetriage.com/reproduction) that doesn't involve puma before reporting upstream....

It might still be useful to share what we've got. I went ahead and filed an upstream reproduction: https://bugs.ruby-lang.org/issues/21560.

So: sleep seems related. But my gist posted above didn’t demonstrate that sleep by itself is a problem. So what new theories do we have to try to reduce the...

I’ve wondered about removing some of the mutexes as well. I think the two options would be not caching counts (in the case of the @todo size), or having a...

> So we should avoid [the sleep](https://github.com/puma/puma/blob/89a448e51b9ba22d46a7a6108fb4787623290dc2/lib/puma/server.rb#L389-L395) for a single worker #3723 is addressing that. It's true that it's not needed, but I've not validated that removing that sleep fixes...