The use case I had in mind would be for gems to include the block registration
in their own code and bypass entirely the Unicorn config. And therefore
bypassing entirely the need for any end user modification of the unicorn config
file.
A gem could include in their code:
if defined?(::Unicorn)
Unicorn.after_fork do
# after fork work
end
end
> It seems like it would be a management problem if the config got
> too big and were split into many pieces. It would be extra bad
> if it were difficult to know ordering (FIFO? LIFO?) and which
> part of the config each part is in.
That’s a valid concern but in my experience, every gem that required an
after_fork call has been an island and order independent from each other. I’m
sure there are exceptions but those would be edge cases.
Plus in all, I can only think of 6-10 common gems off-hand that require manual
after_fork additions. I think the total number of subscribers to this feature
would be limited in the scope of a single application.
>
> You can manage an array yourself:
>
> af_cb = []
> after_fork { af_cb.each(&:call) }
> af_cb << lambda { ... }
> af_cb << lambda { … }
My reason for asking is that as a gem author, asking a user to modify their
unicorn config isn’t ideal. The best solution would be if my gem could auto
register a block to be run post fork and not require the user to do anything
(zero config).
>> (Confronting the ActiveRecord establish_connection and Redis re-connect seem
>> to be a rite of passage into using Unicorn)
>
> preload_app has always defaulted to "false" for this reason :)
Oddly I never realized that - thanks :-) Unfortunately major orgs/gems/libs
that have Unicorn instructions almost always require preload_app true. (for
whatever various reasoning)
> Also, isn't a mere disconnect all that's necessary nowadays, as
> connections are made on demand? At least that's how Sequel
> behaves. I haven't touched AR/Rails in years (since a JS
> engine became mandatory).
Definitely true. The harder case is for background threads and/or actor
threads. Only the calling thread is copied to the new process and others are
non-existent in the new process. after_fork is a handy hook to re-init any
background/actor threads needed.
In any case, those are my thoughts. Not critical but more of a helpful nice to
have.
Best,
Peter
—
Peter Giacomo Lombardo
Ruby Instrumentation Lead
https://github.com/pglombardo
Instana, Inc
https://www.instana.com
