and verify tasks get executed the expected number of times.
Since the part after the yield statement runs to early it
was shutting down the app(s) prematurely.
So far I don't think we have any messages that should survive
restarts. If we do at some point we should route them differently
(or change the existing worker to use ephemeral messages).
Unfortunately adding a third app doesn't seem to work.
In that case only the last 2 apps receive the control task.
I do know that this isn't a problem with real separate processes,
but I don't know what is causing this.
Occasionally we want to wait for a toolbox or data table
reload before continuing, so knowing when that's done
(=wait for the result) is helpful.
Getting the result of a task seems like a good idea,
we could use this for a whole lot of things.
One thing is targeting functions to (remote) handlers
that have access to information that web handlers don't,
like how busy a cluster is or which dependencies are
available or whether a handler is dead.
It's important to not set the DatabaseHeartbeat `server_name` prior to forking,
which we avoid be getting `server_name` from
`application_stack.app.config.server_name`.
`WorkerProcess.server_name` for uwsgi web processes will look like:
`main.web.1` and mules like `main.job-handlers.1` while webless workers
remain named `handler1`.
John Chilton