2011/1/15 Phil Stracchino <alaric@...>
> No. I don't know enough about the internals of the Director to know why
> it is unsafe, but experience has shown that it is. Sooner or later, a
> reload ... perhaps overwrites a buffer or pointer that's in use, perhaps
> tries to replace a structure that is locked because it's in use, I don't
> know exactly what happens; but the reload fails, and from then on the
> Director doesn't work properly until it's restarted.
Well, "Use the source, Luke" :)
A function "void reload_config(int sig)" explains how it works internally:
* If we get here, we have received a SIGHUP, which means to
* reread our configuration file.
* The algorithm used is as follows: we count how many jobs are
* running and mark the running jobs to make a callback on
* exiting. The old config is saved with the reload table
* id in a reload table. The new config file is read. Now, as
* each job exits, it calls back to the reload_job_end_cb(), which
* decrements the count of open jobs for the given reload table.
* When the count goes to zero, we release those resources.
* This allows us to have pointers into the resource table (from
* jobs), and once they exit and all the pointers are released, we
* release the old table. Note, if no new jobs are running since the
* last reload, then the old resources will be immediately release.
* A console is considered a job because it may have pointers to
* resources, but a SYSTEM job is not since it *should* not have any
* permanent pointers to jobs.