The BOINC application programming interface (API)

The BOINC API is a set of C++ functions. Most of the functions have a C interface, so that they can be used from programs written in C and other languages. Unless otherwise specified, the functions return an integer error code; zero indicates success. To use the API include there header.

#include "boinc_api.h"
#include "filesys.h"

BOINC applications may has an associate graphics program, which can act a a screensaver. The API for these graphics apps is here.

Initialization and termination

Initialization must be done before calling other BOINC functions.

boinc_init();

Multi-thread apps: do not create any threads or store the current PID before calling boinc_init().

When the application has completed it must call

int boinc_finish(int status);

status is nonzero if an error was encountered. This call does not return.

Do not call exit(0). If you do, BOINC will restart the app, which is probably not what you want.

Resolving file names

Applications that use named input or output files must call

int boinc_resolve_filename(char *logical_name, char *physical_name, int len);

or

int boinc_resolve_filename_s(char *logical_name, std::string& physical_name);

to convert logical file names to physical names. For example, instead of

f = fopen("my_file", "r");

the application might use

string resolved_name;
retval = boinc_resolve_filename_s("my_file", resolved_name);
if (retval) fail("can't resolve filename");
f = boinc_fopen(resolved_name.c_str(), "r");

Don't use boinc_resolve_filename() for files with the copy_file attribute, or for temporary files. It must be used for all other input or output files specified in the job templates, or files that are part of the application version.

I/O wrappers

Applications should replace fopen() calls with

boinc_fopen(char* path, char* mode);

This deals with platform-specific problems. On Windows, where security and indexing programs can briefly lock files, boinc_fopen() does several retries at 1-second intervals. On Unix, where signals can cause fopen() to fail with EINTR, boinc_fopen checks for this and does a few retries; it also sets the 'close-on-exec' flag.

Checkpointing

Long jobs may want to periodically write the current state of the computation to disk. This is known as checkpointing. The checkpoint file must include everything required to restart the computation at the same point. On startup, the application reads the checkpoint file to determine where to begin computation. If the BOINC client quits or exits, the computation can be restarted from the most recent checkpoint.

Most applications are able to checkpoint only at specific points, e.g. at the end the outer loop. Whan the application is at such a point, it must call

int boinc_time_to_checkpoint();

If this returns nonzero (True) then the application should checkpoint immediately (i.e., write the state file and flush all output files), then call

void boinc_checkpoint_completed();

boinc_time_to_checkpoint() is fast, so it can be called frequently (hundreds or thousands of times a second).

boinc_time_to_checkpoint returns true only when sufficient time has passed since the last checkpoint. This minimum interval is the maximum of:

• A user preference (e.g. laptop users might want to checkpoint infrequently).
• An optional application-supplied, specified by calling

boinc_set_min_checkpoint_period(int nsecs);

If you're using replication, make sure your application generates the same results regardless of where and how often it restarts. This requires:

• In writing the checkpoint file, use conversion codes that don't lose precision; e.g., use %e for doubles.
• If your app uses random numbers, save and restore the state of the RNG. If you use rand(), you can do this by surrounding every boinc_time_to_checkpoint() with the following:

  int x = rand();
  if (boinc_time_to_checkpoint()) {
     ...
  }
  srand(x);
  

Write x to the checkpoint file, and do a srand(x) when restarting from a checkpoint.

Critical sections

void boinc_begin_critical_section();
void boinc_end_critical_section();

Call these around code segments during which you don't want to be suspended or killed by the core client. Since r14694, critical sections are reentrant. This means that you can begin critical section multiple times, but each begin must have a matching end call.

NOTE: This is done automatically while checkpointing.

Atomic file update

To facilitate atomic checkpoint, an application can write to output and state files using the MFILE class.

class MFILE {
public:
    int open(char* path, char* mode);
    int _putchar(char);
    int puts(char*);
    int printf(char* format, ...);
    size_t write(const void* buf, size_t size, size_t nitems);
    int close();
    int flush();
};

MFILE buffers data in memory and writes to disk only on flush() or close(). This lets you write output files and state files more or less atomically.

Reporting progress

The BOINC Manager displays the percent done of tasks in progress. To keep this display current, an application should periodically call

boinc_fraction_done(double fraction_done);

The fraction_done argument is an estimate of the workunit fraction complete (from 0 to 1). This function is fast and can be called frequently (once per second or more). The sequence of arguments in successive calls should be non-decreasing. (An application should not 'reset' and start over if an error occurs; it should call boinc_finish() with a nonzero error code.)

Many applications can supply only an approximate fraction done. If your application can supply an accurate fraction done, set the "exact fraction done" attribute of the app.

Timing information

int boinc_wu_cpu_time(double &cpu_time);

gets the total CPU time (from the beginning of the work unit, not just since the last restart).

double boinc_elapsed_time();

returns the elapsed runtime (i.e. wall-clock time during which the job was not suspended) since the start of the current episode. The elapsed time from earlier episodes is in APP_INIT_DATA::starting_elapsed_time (only from 6.10+ clients).

Standalone mode

BOINC applications can be run in "standalone" mode for testing, or under the control of the BOINC client. You might want your application to behave differently in the two cases. For example you might want to output debugging information if the application is running standalone. To determine if the application is running in standalone mode or under the control of the BOINC client, call

int boinc_is_standalone(void);

This returns non-zero (True) if the application is running standalone, and zero (False) if the application is running under the control of the BOINC client.

Registering a timer handler

typedef void (*FUNC_PTR)();
void boinc_register_timer_callback(FUNC_PTR);

This registers a timer handler function, which will be called once per second.

Temporary exit

If an application is unable to run because of a transient condition, it should call

int boinc_temporary_exit(int delay, const char* reason=NULL, bool is_notice=false);

This will exit the application and tell the BOINC client to restart it again in at least delay seconds. (This works with 6.10.25+ client; on other clients, it will potentially restart immediately). Reason, if supplied, is shown to the user as the explanation for the deferral. If is_notice is true, it's shown as a notice (this should be used only for conditions that the user can fix).

Examples:

• A GPU application fails to allocate GPU RAM because non-BOINC programs have GPU RAM allocated.
• The Vboxwrapper sees that an incompatible version of VirtualBox is installed. In this case "is_notice" would be true, because the user can update VirtualBox.