Jean Boussier

> If it’s such a problem It's wasteful, but not necessarily a problem. > I wonder if AS can somehow mark a freshly parsed object Nah, would mean monkey patching...

> personally I think a second threadpool which is intended only for I/O or mostly-sleeping application container threads might be easier to understand and maintain. Yes, I mention removing the...

I agree a dedicated pool is a cleaner, more intentional implementation.

> Would we ever care to formalize this interface there, or is this too server specific? IMO it's very server specific. It makes no sense in Falcon/Pitchfork/Unicorn, so not worth...

> in short the application code indicates "This segment of code is IO bound" or "This segment of code is CPU bound" Here it's not about declaring the request profile...

> then a fiber based reactor seems better than threads. No, a key part of the design is that this stay on the same fiber and same thread than the...

> I think we also need a limit to this feature or we face hitting thread exhaustion. Yes, as mentioned in https://github.com/puma/puma/issues/3777#issuecomment-3337234298 > What should happen when this limit is...

This was in 2012, I think Puma was already around, but maybe not the default? https://github.com/rails/rails/commit/af0a9f9eefaee3a8120cfd8d05cbc431af376da3 Regardless of Puma or other server, the goal is the same: free up the...

> What if [...] I don't see what it gains you, but also: - This assumes the app has no thread local state (Rails does by default), only fiber local...

> I'm still worried about thread exhaustion. I don't like secret magic limits inside my apps. I mean, even fibers have a limit, they're cheaper than threads, but they still...