A cool feature in the rails engines could be to define callbacks for the case in which a rails app will be forked into a new process.
Why this could be important?
For years, unicorn has warned us to always disconnect and reconnect to the database in its own custom callbacks. Passenger has such callbacks as well.
And this is just for Rails base networking as ActiveRecord (and now we have action cable). Imagine that for every other network-related library (pubsub, API pooling, etc) one always has to define them in the after fork block. This is due to the common anti-pattern (IMO) in rails of placing such code in an initializer. So, if a fork-based server/jobqueue wants to preload the app before forking itself to take advantage of CoW, one has to be really careful about not forgetting to fill in the callbacks from that specific server (this affects unicorn, resque, passenger, at least).
If there was a way to define in the engine stuff to be called before rails process is forked (and after), like we already do for the initialization hooks, it could be possible to define in in on the library level and also in the app itself. The server would therefore only need to batch-execute the Rails app callbacks before and after fork.
This could (in theory) not only benefit the servers I mentioned, but a possible fork-based foreman implementation as well.
