Core/app interaction (basic)
 |
DeprecatedThe information on this page is no longer current. |
Explain startup files
Explain shared memory mechanism in general
Explain work-related use of shmem
Application are executed in separate 'slot' directories, allowing them to create and use temporary files without name conflicts. Input and output files are kept outside the slot directory. The mappings from virtual to physical filenames use 'symbolic link' files in the slot 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 core client and applications is done through XML files in the slot directory. Several files are used.
Files created by the core client, read by the app: (Once, at start of app)
- 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 core client:
The API implementation uses a timer (60Hz). This timer is used for several purposes:
- To tell the app when to checkpoint;
Exit status The core client 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 core passes the WU CPU time in init_data.xml. boinc_checkpoint_completed() and boinc_finish() compute the new WU CPU time, and write it to checkpoint_cpu.xml. The core deletes this after reading. If on exit there is no checkpoint_cpu.xml, it means the app called exit(0) rather than boinc_finish(). In this case the core measures the child CPU itself.
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.
