- Win process control (affects API and wrapper):
Since Win doesn't have an API for process suspend/resume,
we were suspending processes by
1) enumerating all the threads in the system (typically several thousand)
2) suspending those belonging to the given process
The problem: for each thread, the code was calling a function
in diagnostics_win.cpp to see if the thread was exempted from suspension.
This check (which is unnecessary anyway if we're suspending another process)
was surrounded by a semaphore acquire/release.
The result: performance problems.
It could take a minute to suspend the threads.
Solution:
1) do the check for exemption only if we're suspending threads
in our own process (i.e. from the API)
2) if we're suspending multiple processes, enumerate the threads
only once, and see if each one belongs to any of the processes
3) have the wrapper elevate itself to normal priority.
Otherwise it can get preempted for long periods,
sometimes in the middle of scanning the threads.
Note: post-9x versions of Win have a process group API that includes suspend/resume.
We'll switch to this soon.
On some systems they use significant CPU time while VMs are running.
TODO: do this only if we're actually running a VBox app
svn path=/trunk/boinc/; revision=25455
- client: prevent infinite recursion (and stack overflow)
in procinfo.cpp:add_child_totals().
Not sure how this could happen.
svn path=/trunk/boinc/; revision=24191
add a mechanism so that apps can report sub-processes
that are not descendants (e.g., virtual machines)
These processes are then counted as part of the app,
not as "non-BOINC CPU time".
This fixes a bug where processing was incorrectly suspended
because CPU usage by VM apps exceeded the "CPU usage limit" pref.
Implementation:
- the PIDs of the processes in question
are passed from app to client via shared-memory,
in the app_status channel.
A new variant of boinc_report_app_status() supports this.
- the VBox wrapper queries the PID of the VM,
and reports it in this way.
- procinfo_app() includes a new argument: a list of PIDs
that are part of the app, although not ancestrally
related to the main process.
- in the client, ACTIVE_TASK now includes a vector "other_pids".
If this is nonempty, it's passed to procinfo_app().
svn path=/trunk/boinc/; revision=24123
proc_control: controlling processes
procinfo: enumerating and querying processes
run_app_windows: launching apps as other users on Win
svn path=/trunk/boinc/; revision=24120
used for system process info
Old: vector of PROCINFO.
Descendants of a process were found by recursively
iterating through the vector.
Operations are O(n)
New: map of (id, PROCINFO),
and each PROCINFO has a vector of its children.
Operations are O(log(n))
Also combined Mac/Win/Linux variants of code that
was essentially the same.
svn path=/trunk/boinc/; revision=24117
which prevented the client from cleaning up
subprocesses of misbehaving multiprocess apps.
- remote job submission system:
assign physical names to input files (based on their MD5)
rather than having the user provide physical names
- VM apps: eliminate vbox64 plan class. Only vbox.
svn path=/trunk/boinc/; revision=23923
i.e. those that create subprocesses.
Previously, the client's job control options (suspend/resume/quit)
would not work for subprocesses.
Multiprocess apps must initialize with something like:
BOINC_OPTIONS options;
boinc_options_defaults(options);
options.multi_process = true;
boinc_init_options(&options);
Note: an application can be both multi-thread and multi-process.
In this case set options.multi_thread as well.
- wrapper: add support for multi-process apps.
Previously, suspend/resume operations did not work for subprocesses.
If a task is multi-process, you must include
<multi_process>1</multi_process>
in its descriptor.
svn path=/trunk/boinc/; revision=23369
David Anderson