BOINC Client Software/Science Application Interaction - No Graphics
From Unofficial BOINC Wiki
INCOMPLETE AND OUT OF DATE
Explain startup files
Explain shared memory mechanism in general
Explain work-related use of shmem
Science Applications are executed in separate 'catbox' directories, allowing them to create and use temporary files without name conflicts. Input and output files are kept outside the catbox. The mappings from virtual to physical filenames use 'symbolic link' files in the catbox directory. The name of such a file is the virtual name, and the file contains an XML tag with the physical name. (This scheme is used because of the lack of filesystem links in Windows.)
Communication between the BOINC Client Software and Science Applications is done through XML Files in the catbox directory. Several files are used.
Files created by the BOINC Client Software, read by the Science Application: (Once, at start of the Science Application)
- Symbolic link files
- init_data.xml: this contains the initialization data returned by boinc_init() (see above), as well as the minimum Checkpoint Period.
Files created by the API implementation, read by the BOINC Client Software:
- fraction_done.xml: contains the Work Unit's fraction done and the current CPU Time from start of the Work Unit. Written by the timer routine as needed.
- checkpoint_cpu.xml CPU Time (from start of Work Unit) at last checkpoint. Written by checkpoint_completed.
The API implementation uses a timer (60Hz); the real-time clock is not available to applications. This timer is used for several purposes:
- To tell the Science Application when to Checkpoint;
- To regenerate the fraction done file
- To refresh graphics
Exit status The BOINC Client Software does a wait() to get the status. boinc_finish() ends with an exit(status);
Accounting of CPU Time: (note: in Unix, a parent can't get the CPU Time of a child until the child exits. So we're forced to measure it in the child.) The BOINC Client Software passes the Work Unit's CPU Time in init_data.xml. boinc_checkpoint_completed() and boinc_finish() compute the new Work Unit's CPU Time, and write it to checkpoint_cpu.xml. The BOINC Client Software deletes this after reading. If on exit there is no checkpoint_cpu.xml, it means the Science Application called exit(0) rather than boinc_finish(). In this case the BOINC Client Software measures the child CPU itself.
The BOINC Client Software maintains
Timing of checkpoints
The app library maintains time_until_checkpoint, decremented from the timer handler. boinc_time_to_checkpoint() returns nonzero if time_until_checkpoint is zero or less. boinc_checkpoint_completed() resets it.
[edit] Maintaining Fraction Done and Current CPU
These two quantities are transferred from the app library to the core client in the file fraction_done.xml. The parameter time_until_fraction_done_update, passed in the initialization file, determines how often this file is written. It is written from the timer handler.
For multi-program applications, only the active application must write the file. The functions boinc_child_start() and boinc_child_done() tell the app library to stop and start writing the file.
TO DO: this creates disk traffic. Either figure out a way of increasing the period for users who don't want disk access, or don't use disk files.
[edit] UCB Source
[edit] Copyright ©
- 2005 University of California
- 2005 Paul D. Buck
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
