"Subsidiary processes" are
1) descendants
2) "other PIDs" as reported by the app, e.g. VMs which are not descendants
We were failing to clean up these processes in some cases.
- Add a function ACTIVE_TASK::kill_exited_app() for killing the
subsidiary processes of a task whose main process has already exited.
At this point we can't enumerate its current descendants;
but we have the list of descendants from the last time
we computed memory usage (within the last 10 sec).
So kill this, and kill the other PIDs
- call this function when appropriate:
- too many temporary exits
- too many premature exits
- main process has exited in response to abort or quit message
(the existing code failed to kill other PIDs)
- rename ACTIVE_TASK::kill_task() to kill_running_task()
to emphasize its intended use.
Also remove code that, in case of secure install on Windows,
didn't try to kill any subsidiary processes at all;
there used to be a permission problem in doing so, now there isn't.
For now, handle AMD/ATI, NVIDIA or Intel GPUs as before. But for other, "new" vendors, we treat each device as a separate resource, creating an entry for each instance in the COPROCS::coprocs[] array and copying the device name COPROC::opencl_prop.name into the COPROC::type field (instead of the vendor name.)
For devices from "new" vendors, set <gpu_type> field in init_data.xml file to the vendor string supplied by OpenCL. This should allow boinc_get_opencl_ids() to work correctly with these "new" devices without modification.
Currently the server doesn't know about different client "brands",
e.g. HTC Power to Give, Charity Engine, GridRepublic, etc.,
so there's no way to collect statistics about them.
Changes:
- client: at startup, read a "client brand" string from client_brand.txt
(i.e. branded clients will have to include this file in their installer)
Report this string in scheduler requests.
- scheduler: parse this request element,
and store it in host.serialnum as [BOINC|7.4.2|brand]
The "static estimate" is wu.rsc_fpops_est/app_version.flops.
The problem is: what if the elapsed time exceeds this.
In this case we were returning elapsed time,
resulting in a "time remaining" of zero, which is bad.
Instead, use the same exponential model that we use to
estimate fraction done when it's not reported.
This has the advantages that:
- time remaining monotonically decreases
(though potentially at a very slow rate)
- the combo of fraction done, elapsed time, and time remaining
is consistent for apps that don't report fraction done
David Anderson