Provide appropriate mechanism for forking to make GRPC work

[Nowaker]

Is your feature request related to a problem? Please describe.
I'm getting this error when trying to use GRPC in Puma in production deployment which is clustered:

grpc cannot be used between calls to GRPC.prefork and GRPC.postfork_child or GRPC.postfork_parent

To use GRPC, I must call GRPC.prefork and then GRPC.postfork_child or GRPC.postfork_parent depending on the context. However, with current Puma DSL, there is no way to know whether I should call postfork_child or postfork_parent because that information isn't exposed in any way. This isn't enough:

before_fork do
  GRPC.prefork
end

after_worker_fork do |index|
  GRPC.postfork_child # or GRPC.postfork_parent
end

Describe the solution you'd like
Two options:

1. Second parameter in after_worker_fork to indicate whether the current process is a child or a parent.
2. If parent is never used as a worker, introduce after_parent_fork where GRPC.postfork_parent would belong to.

Or, if my understanding is wrong, and there is a way to execute these three GRPC methods properly, a documentation update is needed, and, ideally, an example on how to handle GRPC forking in Puma.

Describe alternatives you've considered
None.

Additional context
Add any other context or screenshots about the feature request here.

[Nowaker]

I started looking at Puma source, and figured this is already possible. I think the language in documentation is confusing, and the only way to really know what is executed where is to look at Puma source.

I think this example should be incorporated into Puma's documentation as it's not possible to use GRPC in clustered Puma without this config.

is_mac = RUBY_PLATFORM.include?('darwin')

on_worker_fork do |index| # Hook name: before_worker_fork
  GRPC.prefork unless is_mac
end

after_worker_fork do |index|
  GRPC.postfork_parent unless is_mac
end

on_worker_boot do
  GRPC.postfork_child unless is_mac
end

[nateberkopec]

Hey @Nowaker, I'm glad you were able to figure it out.

I'm not super happy with the names of our fork hooks either, but it's basically a historical artifact of how they were added on one-by-one over the years.

I wonder if a new set of aliases could make this clearer...

I'm also not super happy with how we don't have a transcription of the full config in DSL in the docs folder. I wonder if we could auto-generate that.

[zedbydade]

Hey @nateberkopec.

By "transcription," do you mean something like a dsl.md file where we'll have the comments from the dsl.rb file? If so, we can generate that by a script and add some configuration examples(Like the GRPC one).

[nateberkopec]

By "transcription," do you mean something like a dsl.md file where we'll have the comments from the dsl.rb file? If so, we can generate that by a script and add some configuration examples(Like the GRPC one).

Yes, exactly!