* Custom IE Javascript interface is gone, it was replaced with a cross-browser Web RPC.
In the HTML doc you can add:
<script type='text/javascript' src='/api/static/boinc.js'></script>
In the JavaScript code you can:
var boinc = new BOINC();
From there you can get the username like:
var userName = boinc.getUserName();
* Default resources are embedded within the executable in much the same way XPM images are embedded in the manager.
/api/static/index.html
/api/static/boinc.png
/api/static/boinc.js
There were two parts to this:
- In the timer thread, we need to check for client death even if
we're in a critical section.
If both conditions hold, set the no_heartbeat status flag.
- In boinc_end_critical_section(), check no_heartbeat and exit if set.
Also: the various checks in boinc_end_critical_section()
(quit, abort, no heartbeat) should be conditioned on
options.direct_process_action.
Otherwise wrappers that use critical sections won't do the right thing.
* the host has GPUs from two different vendors with different OpenCL platforms (e.g., NVIDIA and AMD), and
* the second platform queried has more GPUs than the first one, and
* the requested GPU is a higher numbed one in the second platform.
Sending or receiving trickle messages required setting flags in BOINC_OPTIONS.
There were two problems with this:
1) it wasn't documented
2) it's not necessary; the act of calling boinc_send_trickle_up()
tells the runtime system to do the trickle-up-related stuff.
Furthermore, because intermediate file upload shares message channels
with trickles, these functions also required the option flags
(also undocumented).
With this change, you don't need to set options to use
trickle messages are intermediate file upload.
Vboxwrapper detects known buggy versions of Vbox and calls
boinc_temporary_exit().
The "Incompatible version" message appears in the task status
in the BOINC Manager, where some users may never see it.
It needs to appear as a notice, telling the user to upgrade VBox.
To do this, I added an optional argument to boinc_temporary_exit()
saying that the message should be delivered as a notice.
This is conveyed to the client by adding
a line containing "notice" to the temp exit file.
I changed the client and vboxwrapper to use this.
My last commit did this using a new API call.
But this would require rebuilding apps any time you want to change it;
too much work.
So instead make it an attribute of apps,
which you can set via the admin web interface.
Corresponding changes to client.
Currently the duration estimate for a task is a combination of
- a static estimate, based on wu.rsc_fpops_est and the estimated FLOPS
- a dynamic estimate, based on fraction done (FD) and elapsed time
The weighting of the dynamic estimate is FD^2;
the assumption is that fraction done is imprecise and improves
toward the end of a task.
This isn't ideal for apps that can supply accurate FD.
Solution: add a new API function
boinc_fraction_done_exact().
This notifies the client that the FD is accurate,
and that it should use only the dynamic estimate.
(New clients will do this; old clients will use the FD as the currently do).
Per-thread signal masking doesn't work in Android pre-4.1.
As a result, the SIGALRM signals used by the BOINC runtime system,
which are supposed to be handled by the worker thread,
sometimes are handled by the timer thread.
As a result, suspended apps never resume.
Workaround: in the SIGALRM handler, see if we're the timer thread.
If so, use pthread_kill() to send a SIGALRM to the work thread, and return.
Trying to fix bug where timer thread stops doing anything
after first suspend on Android (old, 1-core devices).
I suspect that the sleep() in the worker thread's signal handle
is sleeping the entire process.
Insert a sched_yield() before the sleep so that the time thread will run.
- If you run the client with --run_test_app,
runs "test_app" in the current directory and interacts with it
(and does nothing else).
It can suspend/resume it with arbitrary timing;
this is controlled in run_test_app() (app_start.cpp).
- example app: add --critical_section option.
This lets you test the runtime system for apps that do
most of their work in a critical section (like GPU apps).
- Add some logging messages (conditioned by DEBUG_BOINC_API)
to the runtime system.
- boinc_finish() waits for the timer thread to write final messages;
make sure it doesn't do anything else
(like suspend the worker thread) during this period
Old: if the timer thread gets a <suspend> message while we're in
a critical section, it sets a "suspend_request" flag.
The timer then periodically (10X/sec) checks whether
suspend_request is set and we're no longer in a critical section;
if so it suspends the worker thread.
Problem (pointed out by Oliver): this doesn't work if the worker thread
is almost always in a critical section
(as is the case for GPU apps, which treat GPU kernels as critical sections).
The app never gets suspended.
New:
1) boinc_end_critical_section() checks suspend_request;
if set, it calls suspend_activities()
2) On Unix, if suspend_activities() is called from the worker thread,
it calls sleep() in a loop until the suspension is over.
(Note: pthreads has no suspend/resume).
3) Add a mutex to protect the data structures shared between
the timer and worker threads.
Oliver pointed out that
David Anderson