Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues 1 Packages Projects Releases Wiki Activity

*** empty log message *** 

svn path=/trunk/boinc/; revision=4681
This commit is contained in:
David Anderson 2004-11-29 22:26:34 +00:00
parent ee26ba1d6e
commit 92e9c8a6b6
26 changed files with 204 additions and 227 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
checkin_notes
View File

@ -20336,3 +20336,16 @@ Bruce 2004-11-29
html/inc
db_ops.inc
util.inc
David 29 Nov 2004
- scheduler: use safe_strncpy instead of strncpy for copying
stderr_out and xml_doc_out.
client/
test_http.C
test_net_xfer.C
doc/
various
sched/
assimilator.C
handle_request.C

4
client/test_http.C
View File

@ -18,6 +18,10 @@ static volatile const char *BOINCrcsid="$Id$";
// Contributor(s):
//
// THIS FILE IS DEPRECATED.
// ITS ORIGINAL PURPOSE WAS TO TO TEST THE HTTP LAYER IN ISOLATION,
// BUT THIS IS NO LONGER POSSIBLE
#include "cpp.h"
#ifdef _WIN32

4
client/test_net_xfer.C
View File

@ -18,6 +18,10 @@ static volatile const char *BOINCrcsid="$Id$";
// Contributor(s):
//
// THIS FILE IS DEPRECATED.
// ITS ORIGINAL PURPOSE WAS TO TEST THE FILE XFER LAYER IN ISOLATION,
// BUT THIS IS NO LONGER POSSIBLE
#include "cpp.h"
#include <stdio.h>

10
doc/account.php
View File

@ -11,16 +11,16 @@ This involves filling out a form with
<ul>
<li> An email address.
<li> A public 'screen name' (real name or nickname).
<li> other optional information
<li> Other optional information
</ul>
<li> You will receive an email containing an <b>account ID</b>
<li> You will receive an email containing an <b>account key</b>
(a long random string).
<li> Download, install and run the BOINC client program.
It will ask for a project URL and an account ID.
It will ask for a project URL and an account key.
Enter the project's URL,
cut and paste the account ID from the email.
cut and paste the account key from the email.
</ol>
<p>
@ -36,7 +36,7 @@ you can add new computers in either of two ways:
<ol>
<li> Download and install the BOINC client program on each computer,
and cut and paste the project URL and account ID as above.
and cut and paste the project URL and account key as above.
<li> If the new computer is the same type as an existing computer,
create a BOINC directory on the new computer,

10
doc/app.php
View File

@ -19,11 +19,8 @@ An application version can consist of multiple files: for example, a
controller script, pre- and post-processing programs, and a primary program.
<p>
Each application version has an integer <b>version number</b>.
This number is of the form 100*major + minor;
for example, 304 represents major version 3 and minor version 4.
An application version will only run on a core client
having the same major version.
Each application version has an integer
<a href=boinc_version>version number</a>.
Version numbers should be used consistently across platforms;
Windows version 304 should be computationally identical to Mac version 304.
@ -38,7 +35,7 @@ Application versions are maintained in the <b>app_version</b> table
in the BOINC DB.
Each entry includes an XML document describing the
files that make up the application version:
<pre>".htmlspecialchars("
".html_text("
<file_info>
...
</file_info>
@ -54,7 +51,6 @@ files that make up the application version:
<file_name>library_12</file_name>
</file_ref>
</app_version>")."
</pre>
Application versions can be created using
<a href=tool_update_versions.php>update_versions</a>.
";

20
doc/backend_state.php
View File

@ -9,11 +9,10 @@ can be described in terms of transitions of their state variables.
<h3>Workunit state variables</h3>
<p>
Several workunits parameters are described
<a href=work.php>here</a>.
Workunits parameters are described <a href=work.php>here</a>.
Other workunit state variables are described in
the following table:
<p>
Workunit state variables are as follows:
";
list_start();
list_item(
@ -103,15 +102,7 @@ Notes on deletion of input files:
but only when all results have state=OVER
(so that clients don't get download failures)
and the WU has been assimilated
(in case the project wants to examine input files in error case).
<li>
All output files (including errors) are retained
until the WU has been assimilated.
After that,
the canonical result output files are retained until
all other results are over and (if necessary) validated.
Error output files can be deleted immediately.
Success output files can be deleted after validation.
(in case the project wants to examine input files in error cases).
</ul>
<h3>Result state variable</h3>
@ -203,9 +194,10 @@ Result invariants:
Notes on deletion of output files:
<ul>
<li> Non-canonical results can be deleted as soon as the WU is assimilated.
<li> Canonical results can be deleted only when all results have server_state=OVER.
<li> Canonical results can be deleted only when all results have server_state=OVER and all success results are validated.
<li> If a result reply arrives after its timeout,
the output files can be immediately deleted.
</ul>
How do we delete output files that arrive REALLY late?
(e.g. uploaded after all results have timed out, and never reported)?

32
doc/boinc_version.php
View File

@ -4,31 +4,29 @@ page_head("Versions of BOINC");
echo "
<p>
The BOINC software (core client and all the server components)
will evolve over time.
The BOINC software (including client and server components)
evolve over time.
There are a number of pairwise interactions
in which version mismatches could cause problems:
<ul>
<li> RPC from core client to scheduling server.
<li> RPC from core client to file upload handler.
<li> Interface between core client and application (uses shared memory).
<li> Interface between core client and application.
<li> Interface between BOINC DB and all BOINC back-end components.
<li> The parsing of the core state file by the core client.
</ul>
<p>
Each version of the BOINC software has a major and minor version number.
The client's version number is included in
scheduler and file upload RPC requests.
If a server receives a request from a client with a different major version,
it returns an error.
Each BOINC software component has a version number
of the form 100*X + Y,
where X and Y are the major and minor versions.
<p>
Some changes to the BOINC server software may involve
changes to the BOINC database
(e.g. adding a new table or field).
Such releases will include SQL script for modifying an
existing database in-place.
In general, all the parts of a BOINC system must
have the same major version.
A core client can interact with servers,
and can execute applications,
only if they have the same major version.
<p>
Major-version changes to the BOINC software will require
@ -52,8 +50,12 @@ The core client reads the version number from the old
client state file, and discards the results.
<p>
TODO: figure out how this interacts with work sequences.
Don't want to relocate a sequence needlessly.
Some changes to the BOINC server software may involve
changes to the BOINC database
(e.g. adding a new table or field).
Such releases will include SQL script for modifying an
existing database in-place.
";
page_tail();
?>

2
doc/client_data.php
View File

@ -46,7 +46,7 @@ such as sets of finite-state machines.
When the core client starts up (CLIENT_STATE::init())
it parses the prefs file, creating a PREFS object.
(If there is no prefs file, it prompts the user for
a project and account ID, and creates one.)
a project and account key, and creates one.)
It then copies the vector of PROJECT objects to CLIENT_STATE.
<p>
Next, it parses the client_state.xml file.

2
doc/client_unix.php
View File

@ -19,7 +19,7 @@ list_start();
list_item("-attach_project",
"Attach this computer to a new project.
You must have an account with that project.
You will be asked for the project URL and the account ID."
You will be asked for the project URL and the account key."
);
list_item("-show_projects",
"Print a list of projects to which this computer is attached."

2
doc/client_windows.php
View File

@ -94,7 +94,7 @@ The work manager's menu items are as follows:
<li> <b>Attach to Project</b>:
Enroll this computer in a project.
You must have already created an account with the project.
You will be asked to enter the project's URL and your account ID.
You will be asked to enter the project's URL and your account key.
<li> <b>Proxy Server</b>
If you connect to the web through an HTTP or SOCKS proxy,
use this dialog to enter its address and port.

34
doc/download.php
View File

@ -6,7 +6,7 @@ function version_start($num, $date, $xml) {
if ($xml) return;
list_start();
list_bar("Version $num (released $date)");
list_heading("Platform", "click to download", "MD5 checksum");
list_heading("Platform", "click to download", "MD5 checksum of download file");
}
function version($platform, $filename, $xml) {
@ -63,33 +63,29 @@ if ($_GET["xml"]) {
page_head("Download BOINC client software");
echo "
<p>
Learn more about BOINC
<a href=http://boinc.berkeley.edu/participate.php>here</a>.
<h2>System requirements</h2>
The BOINC core client is available for the following platforms:
<ul>
<li> Windows (95 and up)
<li> Linux/x86
<li> Solaris/SPARC
<li> Mac OS X
</ul>
<p>
There are no specific hardware requirements
(CPU speed, RAM, disk space, etc.).
(CPU speed, memory, disk space, etc.).
However, these factors may limit the amount or type
of work that is sent to your computer.
Each 'work unit' has minimum RAM and disk requirements,
and a deadline for completion of its computation.
A BOINC project won't send a work unit to a computer that can't handle it.
<p>
<h2>Stable version (recommended)</h2>
<h2>Current version</h2>
";
show_413();
echo "
After the download is finished:
<ul>
<li><b>Windows</b>:
open the downloaded file.
This will install BOINC on your computer.
<li><b>Macintosh OS X, Unix and Linux</b>:
Use gunzip to uncompress if your browser has not done it for you.
Then chmod +x the executable and run it.
</ul>
<p>
If your computer is not one of the above types, you can
<ul>
<li> <a href=anonymous_platform.php>download and compile the BOINC software yourself</a> or

53
doc/files.php
View File

@ -12,24 +12,24 @@ The BOINC core client transfers files to and from <b>data servers</b>
operated by the project, using HTTP.
<p>
A file is described by an XML element of the form
<pre>
&lt;file_info>
&lt;name>foobar&lt;/name>
&lt;url>http://a.b.c/foobar&lt;/url>
&lt;url>http://x.y.z/foobar&lt;/url>
".html_text("
<file_info>
<name>foobar</name>
<url>http://a.b.c/foobar</url>
<url>http://x.y.z/foobar</url>
...
&lt;md5_cksum>123123123123&lt;/md5_cksum>
&lt;nbytes>134423&lt;/nbytes>
&lt;max_nbytes>200000&lt;/max_nbytes>
&lt;status>1&lt;/status>
[ &lt;generated_locally/> ]
[ &lt;executable/> ]
[ &lt;upload_when_present/> ]
[ &lt;sticky/> ]
[ &lt;signature_required/> ]
[ &lt;no_delete/> ]
&lt;/file_info>
</pre>
<md5_cksum>123123123123</md5_cksum>
<nbytes>134423</nbytes>
<max_nbytes>200000</max_nbytes>
<status>1</status>
[ <generated_locally/> ]
[ <executable/> ]
[ <upload_when_present/> ]
[ <sticky/> ]
[ <signature_required/> ]
[ <no_delete/> ]
</file_info>
")."
The elements are as follows:
";
list_start();
@ -66,9 +66,8 @@ if a particular input file or files are used by more than one
workunit, or will be used by future, unqueued workunits.");
list_item("no_delete", "If present for an output (result) file,
indicates that the file should NOT be removed from the upload/
directory when the corresponding workunit is completed. This is
probably a bad idea since your upload/ directory will eventually
overflow!");
directory when the corresponding workunit is completed.
Use with caution - this may cause your upload/ directory to overflow.");
list_end();
echo "
These attributes allow the specification of various types of files: for
@ -83,13 +82,13 @@ Files may be associated with <a href=work.php>workunits</a>,
<a href=result.php>results</a> and
<a href=app.php>application versions</a>.
Each such association is represented by an XML element of the form
<pre>
&lt;file_ref>
&lt;file_name>foobar&lt;/file_name>
[ &lt;open_name>input&lt;/open_name> ]
[ &lt;main_program/> ]
&lt;/file_ref>
</pre>
".html_text("
<file_ref>
<file_name>foobar</file_name>
[ <open_name>input</open_name> ]
[ <main_program/> ]
</file_ref>
")."
The elements are as follows:
";
list_start();

2
doc/gui_urls.php
View File

@ -52,7 +52,7 @@ list_item(htmlspecialchars("<user_name/>"), "The user name");
list_item(htmlspecialchars("<teamid/>"), "The team ID");
list_item(htmlspecialchars("<team_name/>"), "The team name");
list_item(htmlspecialchars("<hostid/>"), "The host ID");
list_item(htmlspecialchars("<authenticator/>"), "The user's account ID");
list_item(htmlspecialchars("<authenticator/>"), "The user's account key");
list_end();
page_tail();
?>

7
doc/index.php
View File

@ -70,7 +70,7 @@ BOINC-based distributed computing projects include:
<ul>
<li>
<a href=http://climateprediction.net>Climateprediction.net</a>:
Improve the accuracy of long-range climate prediction.
Improve the accuracy of long-term climate prediction.
<li>
<a href=http://www.physics2005.org/events/einsteinathome/index.html>Einstein@home</a>:
search data from the Laser Interferometer Gravitational wave Observatory (LIGO)
@ -80,10 +80,9 @@ in the US and from the GEO 600 gravitational wave observatory in Germany for sig
improve the design of the CERN LHC particle accelerator.
<li>
<a href=http://predictor.scripps.edu>Predictor@home</a>:
Solve biomedical questions of protein-related diseases.
Solve biomedical questions and investigate protein-related diseases.
<li><a href=http://setiweb.ssl.berkeley.edu/>SETI@home</a>:
Analyze radio-telescope data,
looking for evidence of extraterrestrial life.
Analyze radio-telescope data, looking for evidence of extraterrestrial life.
</ul>
We encourage you to participate in multiple projects,
so that your computer will be kept busy even

2
doc/intro.php
View File

@ -4,7 +4,7 @@ page_head("Overview of BOINC");
echo"
<p>
BOINC is a software platform for distributed computing
using volunteer computer resources.
using volunteered computer resources.
<p>
A paper about BOINC's design goals is here:
<a href=http://boinc.berkeley.edu/talks/madrid_03/madrid.html>HTML</a> |

4
doc/intro_user.php
View File

@ -11,10 +11,10 @@ echo "
Go to the project's web site, click on <b>Create Account</b>,
and fill out the form.
You will receive an email containing
your <b>account ID</b> (a long random string).
your <b>account key</b> (a long random string).
Save this email.
<li> <b><a href=download.php>Download</a> and install BOINC.</b>
You will be asked to enter the project's URL and your account ID.
You will be asked to enter the project's URL and your account key.
</ul>
That's it!
<p>

6
doc/multiple_projects.php
View File

@ -10,11 +10,11 @@ You can join a second and subsequent projects as follows.
You don't have to use the same email address,
but if you do so the accounts will be 'coupled'
in terms of preferences and statistics.
<li> Receive an email containing an account ID.
<li> Paste the account ID into the project's web site
<li> Receive an email containing an account key.
<li> Paste the account key into the project's web site
to complete the account creation.
<li> Run the BOINC client, and select the <b>Attach to Project</b> command.
Enter the project's URL and your account ID.
Enter the project's URL and your account key.
</ol>

23
doc/project_cookbook.php
View File

@ -6,13 +6,21 @@ echo "
<ul>
<li> Compile the BOINC software, say into HOME/boinc.
Make sure MySQL is configured and running.
<li> run HOME/boinc/tools/make_project
<li> paste text into httpd.conf
<li> insert cron job
<li> xadd project.xml
<li> Run HOME/boinc/tools/<a href=make_project.php>make_project</a>
<li> Append the contents of projects/PROJECT/PROJECT.httpd.conf
to httpd.conf and restart Apache.
<li> Insert a cron job to run the project's periodic tasks, e.g.
<br> 0,5,10,15,20,25,30,35,40,45,50,55 * * * * HOME/projects/PROJECT/bin/start --cron
<br> (if cron cannot run 'start', try using a helper script
to set PATH and PYTHONPATH)
<li> Copy project.xml from HOME/boinc/tools to HOME/projects/PROJECT,
edit it to taste,
and run <a href=tool_xadd.php>bin/xadd</a>.
<li> Edit html/project/project.inc, changing the
master URL and copyright holder.
<li> Add .htaccess and .htpasswd files to html/ops.
<li> Using <a href=http://httpd.apache.org/docs/programs/htpasswd.html>htpasswd</a>,
add .htaccess and .htpasswd files to html/ops.
</ul>
Visible result: the project web site is up.
@ -57,7 +65,8 @@ html_text(
"
</ul>
Visible result: 'status' shows the above daemon processes running.
Visible result: after a project restart,
'status' shows the above daemon processes running.
<p>
Troubleshooting: check the log files of all daemon processes.
@ -67,7 +76,7 @@ Troubleshooting: check the log files of all daemon processes.
Copy the core client there.
<li> Using the web interface, create an account on the project.
<li> Run the core client;
enter the project URL and the account ID.
enter the project URL and the account key.
</ul>
Visible result: the client does a stream of work;

15
doc/result.php
View File

@ -5,7 +5,13 @@ echo "
<p>
A <b>result</b> describes an instance of a computation, either unstarted,
in progress, or completed.
The attributes of a result include:
Each result is described by an entry in the 'result' database table.
A project does not explictly create results;
rather, BOINC creates them automatically for <a href=work.php>workunits</a>,
based on the redundancy parameters of the workunit.
<p>
The static attributes of a result include:
";
list_start();
list_item(
@ -13,12 +19,17 @@ list_item(
"A text string, unique across all results in the project."
);
list_item(
"workunit name", "Identifies the associated workunit"
"workunit name", "Identifies the associated <a href=work.php>workunit</a>"
);
list_item("output files",
"A list of the names of the output files,
and the names by which the application refers to them."
);
list_end();
echo "
A result has a dynamic attribute:
";
list_start();
list_item("server state",
"Values include:
<ul>

2
doc/security.php
View File

@ -107,7 +107,7 @@ public-participation computing in general.
<p>
<b>Theft of participant account information by network attack</b>
<p>
Attackers sniffing network traffic could get user's account IDs,
Attackers sniffing network traffic could get user's account keys,
and use them to get the user's email address,
or change the user's preferences.
BOINC does nothing to prevent this.

51
doc/tool_add.php
View File

@ -1,51 +0,0 @@
<?php
require_once("docutil.php");
page_head("add - tool for adding database items");
echo "
<b>add</b> is a command-line tool for adding entries to the BOINC database.
<p>
<b>add is deprecated - we recommend using <a href=tool_xadd.php>xadd</a> instead.</b>
<p>
Usages:
<pre>
add project --name=sah --long_name=\"SETI@home\"
add platform --name=windows [ --user_friendly_name=\"Windows (95, NT, XP)\" ]
add core_version --platform=c64 --version_num=717
--exec_file=/path/to/boinc_7.17_c64
[--message=\"Message\"] [--message_priority=\"Priority\"]
add app --name=YetiApp [--min_version=716]
add app_version --app=YetiApp --platform=c64 --version_num=717
--exec_file=/path/to/yeti_7.17_c64
[--signature_file=/path/to/sig_file]
[--exec_file=/path/to/more_bins
[--signature_file=/tmp/sig_file2]] ...
add user --name=\"Carl Sagan\" --email_addr=\"carl.sagan@example.com\"
--authenticator=\"deadbeef\"
[--country=Estonia --postal_code=94703
--global_prefs_file=/path/to/prefs.xml]
</pre>
For detailed help, type `<code>add</code>' (with no arguments) or `<code>add
app_version</code>' for help on adding an app_version, etc.
<p>
Typically you will only <code>add</code> <code>platform</code>s
and <code>app</code>s, and only at the inception of the project.
A project is created with <a href=make_project.php>make_project</a>.
Core_version and app_version are automatically added by the
<a href=tool_update_versions.php>update_versions</a> tool.
Users are usually created through the Web interface.
";
page_tail();
?>

26
doc/tool_xadd.php
View File

@ -3,7 +3,7 @@
page_head("xadd - tool for adding database items");
echo "
<b>xadd</b> adds records to the BOINC database.
<b>xadd</b> adds platform and application records to the BOINC database.
Information is read from an XML file,
<b>project.xml</b>.
This file should be in the project's root directory.
@ -13,6 +13,11 @@ The contents of <b>project.xml</b> should look like this:
<pre>", htmlspecialchars("
<boinc>
<app>
<name>setiathome</name>
<user_friendly_name>SETI@home</user_friendly_name>
</app>
...
<platform>
<name>windows_intel</name>
<user_friendly_name>Windows 95, 98, NT 2000, and XP</user_friendly_name>
@ -22,17 +27,16 @@ The contents of <b>project.xml</b> should look like this:
"), "</pre>
<p>
An example is in tools/ in the source tree.
The 'name' of each item should be short
and without spaces or other special characters.
The 'user friendly name' (shown to end users) has no restrictions.
<p>
Notes:
<ul>
<li>Object arguments have the same format as for the `add' tool
command-line arguments. See also the <a href=tool_add.php>documentation
for `add'</a>.
<li>This tool (currently) only adds new items;
Entries that conflict with existing database entries are ignored.
</ul>
An example of projects.xml is in tools/ in the source tree.
<p>
This tool only adds new items;
entries that conflict with existing database entries are ignored.
";
page_tail();
page_tail();
?>

2
doc/validate.php
View File

@ -71,6 +71,8 @@ check_pair() should return nonzero if a major error occurs.
This tells the validator to write an error message and exit.
</ul>
<p>
Neither function should delete files.
<p>
Two example validators are supplied
(each implements check_set() and check_pair()):

50
doc/work.php
View File

@ -4,7 +4,12 @@ page_head("Workunits");
echo "
<p>
A <b>workunit</b> describes a computation to be performed.
Its attributes include:
It is represented by a row in the 'workunit' database table.
BOINC provides a <a href=tools_work.php>utility program and C function</a>
for creating workunits.
<p>
A workunit has several attributes that are specified
when the workunit is created:
";
list_start();
@ -31,13 +36,13 @@ list_item(
"priority",
"Higher-priority work is dispatched first"
);
list_end();
echo "
A workunit includes estimates of, and bounds on,
its resource usage.
";
list_start();
list_item(
"batch",
"An integer; can be used to operate
(cancel, change priority etc.)
on groups of workunits."
);
list_bar("Resource estimates and bounds");
list_item(
"rsc_fpops_est",
"An estimate of the average number of floating-point operations
@ -66,16 +71,7 @@ list_item(
at least this much available disk space.
If this bound is exceeded, the application will be aborted."
);
list_end();
echo "
<p>
A workunit has several parameters related to redundancy and scheduling.
Values for these parameters are supplied by the project
when the workunit is created.
";
list_start();
list_bar("Redundancy and scheduling attributes");
list_item(
"delay_bound",
"An upper bound on the time (in seconds) between sending
@ -101,9 +97,9 @@ list_item(
);
list_item(
"target_nresults",
"How many successful results to get.
"How many results to create initially.
This must be at least <b>min_quorum</b>.
It may be more to reflect the ratio of result loss,
It may be more, to reflect the ratio of result loss,
or to get a quorum more quickly."
);
list_item(
@ -111,8 +107,7 @@ list_item(
"If the number of client error results exceeds this,
the work unit is declared to have an error;
no further results are issued, and the assimilator is triggered.
This safeguards against workunits that cause
the application to crash."
This safeguards against workunits that cause the application to crash."
);
list_item(
"max_total_results",
@ -131,11 +126,11 @@ list_item(
list_end();
echo "
A workunit that is in the system has the following attribute:
A workunit has a dynamic attribute:
";
list_start();
list_item(
"error mask",
"<nobr>error mask</nobr>",
"A bit mask of various error conditions:
<ul>
<li> <b>WU_ERROR_COULDNT_SEND_RESULT</b>:
@ -145,6 +140,7 @@ list_item(
were too large for the hosts,
or because no application version was available
for the hosts' platforms.
In this case BOINC 'gives up' on the workunit.
<li> <b>WU_ERROR_TOO_MANY_ERROR_RESULTS</b>:
Too many results with error conditions
(upload/download problem, client crashes)
@ -161,9 +157,9 @@ list_item(
);
list_end();
echo "
<p>
BOINC provides a <a href=tools_work.php>utility program and C function</a>
for creating workunits.
If any of these conditions holds,
BOINC 'gives up' on the workunit and doesn't
dispatch more results for it.
";
page_tail();

51
sched/assimilator.C
View File

@ -59,16 +59,17 @@ bool do_pass(APP& app) {
char buf[256];
int retval;
check_stop_daemons();
sprintf(buf, "where appid=%d and assimilate_state=%d limit 1000", app.id, ASSIMILATE_READY);
while (!wu.enumerate(buf)) {
vector<RESULT> results; // must be inside while()!
// for testing purposes, can pretend we did nothing.
if (update_db)
did_something = true;
// for testing purposes, pretend we did nothing
//
if (update_db) {
did_something = true;
}
log_messages.printf(SCHED_MSG_LOG::DEBUG,
"[%s] assimilating; state=%d\n", wu.name, wu.assimilate_state
@ -84,19 +85,19 @@ bool do_pass(APP& app) {
assimilate_handler(wu, results, canonical_result);
if (did_something) {
sprintf(
buf, "assimilate_state=%d, transition_time=%d",
ASSIMILATE_DONE, (int)time(0)
);
retval = wu.update_field(buf);
if (retval) {
log_messages.printf(SCHED_MSG_LOG::CRITICAL,
"[%s] update failed: %d\n", wu.name, retval
);
exit(1);
}
}
if (update_db) {
sprintf(
buf, "assimilate_state=%d, transition_time=%d",
ASSIMILATE_DONE, (int)time(0)
);
retval = wu.update_field(buf);
if (retval) {
log_messages.printf(SCHED_MSG_LOG::CRITICAL,
"[%s] update failed: %d\n", wu.name, retval
);
exit(1);
}
}
}
if (did_something) {
boinc_db.commit_transaction();
@ -121,15 +122,15 @@ int main(int argc, char** argv) {
log_messages.set_debug_level(atoi(argv[++i]));
} else if (!strcmp(argv[i], "-app")) {
strcpy(app.name, argv[++i]);
} else if (!strcmp(argv[i], "-dont_update_db")) {
// This option is for testing your assimilator. When set,
// it ensures that the assimilator does not actually modify
// the assimilate_state of the workunits, so you can run
// your assimilator over and over again without affecting
// your project.
update_db = false;
} else if (!strcmp(argv[i], "-dont_update_db")) {
// This option is for testing your assimilator. When set,
// it ensures that the assimilator does not actually modify
// the assimilate_state of the workunits, so you can run
// your assimilator over and over again without affecting
// your project.
update_db = false;
} else {
log_messages.printf(SCHED_MSG_LOG::CRITICAL, "Unrecognized arg: %s\n", argv[i]);
log_messages.printf(SCHED_MSG_LOG::CRITICAL, "Unrecognized arg: %s\n", argv[i]);
}
}

4
sched/handle_request.C
View File

@ -431,8 +431,8 @@ int handle_results(
#endif
srip->server_state = RESULT_SERVER_STATE_OVER;
strncpy(srip->stderr_out, rp->stderr_out, sizeof(srip->stderr_out));
strncpy(srip->xml_doc_out, rp->xml_doc_out, sizeof(srip->xml_doc_out));
safe_strncpy(srip->stderr_out, rp->stderr_out, sizeof(srip->stderr_out));
safe_strncpy(srip->xml_doc_out, rp->xml_doc_out, sizeof(srip->xml_doc_out));
// look for exit status and app version in stderr_out
// (historical - can be deleted at some point)