How does it compare to puma?
> what's the main benefit?
Drastically reduced memory usage by improving Copy-on-Write performance. For mid-sized apps it can even use less memory than puma depending on how you set it up. See this synthetic benchmark.
> Why did you decide to build reforking into a fork of Unicorn instead of contributing it to Puma?
Mostly for simplicity. You can build this in Puma, but there are a few extra challenges. For instance you don't want to refork when another thread is currently processing a request, you'd risk leaving some global resource in a corrupted state. So you'd first need to stop accepting traffic and wait for all requests to complete. The problem is, Puma doesn't have a request timeout, so if the request never complete, what do you do? Lots of small challenges like that. But I think it would be awesome if Puma was to take back that idea. Puma's fork_worker feature was a big part of the inspiration after all, and I'd even be happy to help Nate or someone else do it.
By comparison, Unicorn (the project upon which Pitchfork is based) is a single-thread, multi-process Rack HTTP server that does not buffer requests, so it's only designed for fast clients (or it needs to be paired with a proxy like Nginx to handle slow clients).
The narrower design of Unicorn results in a simpler, less-flexible potentially more efficient architecture.
The reforking feature that Pitchfork introduces to Unicorn was originally implemented in Puma [1], though they're controlled differently and the underlying implementations are entirely different.
[1] https://github.com/puma/puma/blob/master/5.0-Upgrade.md#fork...