- 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.
PRINCIPLE: AVOID PER-GPU-TYPE VARIABLES
- get rid of alloca() stuff in gutil.cpp; almost certainly not needed
- don't include malloc.h; it doesn't exist on BSD systems
Old: heartbeat mechanism
Problem: if the client is blocked for > 30 secs
(e.g. because it takes a long time to write the state file,
of because it's stopped in a debugger)
then apps exit.
This is bad is the app doesn't checkpoint and has been
running for a long time.
New: the client passes its PID to the app.
The app periodically (10 sec) checks that the process still exists.
Notes:
- For backward compatibility (e.g. new API w/ old client,
or vice versa) the client still sends heartbeats,
and the API checks heartbeats if the client doesn't pass a PID.
- The new mechanism works only if the client's PID isn't assigned
to a new process within 10 secs of the client exiting.
Windows 2000 reuses PIDs immediately, so check for Win2K
and don't use this mechanism if so.
TODO: For Unix multithread apps,
critical sections aren't currently being enforced.
Need to fix this by masking signals.
svn path=/trunk/boinc/; revision=26147
clear the suspend_request flag.
Otherwise we'll end up doing two suspends,
and on Win the app will be suspended forever.
svn path=/trunk/boinc/; revision=26143
Lets application specify a min checkpoint interval.
The actual min checkpoint interval is the max of this
and the user-specified pref for min disk interval.
svn path=/trunk/boinc/; revision=26005
- Fix various #include issues.
CODING STYLE LAW (minimal inclusion principle):
If foo.cpp requires <blah.h>,
#include <blah.h> in foo.cpp, NOT foo.h
svn path=/trunk/boinc/; revision=25837
moved app_ipc.h inclusion outside __cplusplus
since it contains important C mode prototypes
(boinc_resolve_filename() etc.)
svn path=/trunk/boinc/; revision=25752
lets an application report its network usage to BOINC,
and hence take it into account with monthly limits etc.
- API: get rid of deprecated boinc_ops_per_cpu_sec(),
boinc_ops_cumulative(), and
boinc_set_credit_claim();
- admin web: update manage_apps.php;
add the ability to set homogeneous app version
svn path=/trunk/boinc/; revision=25700
and it timed out and we killed it, we'd treat it as a job error.
(This was a major bug).
- API: remove BOINC_STATUS::suspend_request.
I meant to do this before.
svn path=/trunk/boinc/; revision=25498
boinc_temporary_exit(),
explaining why the app is exiting.
Convey this to the client, and then to the Manager,
and display it there and in the log.
clientgui/
MainDocument.cpp
lib/
gui_rpc_client_ops.cpp
gui_rpc_client.h
api/
boinc_api.cpp,h
client/
client_types.cpp,h
app.h
app_control.cpp
svn path=/trunk/boinc/; revision=25315
core client. Next commit will create an extra "VM Console"
button in the manager when detected. Volunteers will just have
to click the button to see what is going on with the VM.
api/
boinc_api.cpp, .h
samples/vboxwrapper
vbox.cpp, .h
vboxwrapper.cpp, .h
svn path=/trunk/boinc/; revision=25035