In practice, forks and threads are at odds with each other. If you try to fork while there are active threads, you will very likely run into bugs. Even if you didn't create the thread, some other library might have, so it can be very tricky in practice.

This very much appears to be a bug or design flaw in puma - The fact that a persistent connection ties up a thread on the chance a request might come over that connection seems like not great behavior. This would really only be an issue when puma is run with no workers (which wouldn't be done in production) but it still seems a little nuts.

ruby-prof provides two options to specify which threads should be profiled: exclude_threads:: Array of threads which should not be profiled. include_threads:: Array of threads which should be profiled. All other threads will be ignored.