1 | | 3) application structure options |
2 | | runtime environment (disk) |
3 | | simple/compound |
4 | | wrapper |
5 | | FORTRAN |
6 | | Java, Python, Lisp |
| 1 | = BOINC applications = |
| 2 | |
| 3 | BOINC lets you distribute pretty much any existing application program, |
| 4 | written in any language. |
| 5 | However, there are a few details you need to know. |
| 6 | First, it's helpful to understand the environment in which |
| 7 | BOINC executes applications. |
| 8 | This has two aspects: |
| 9 | |
| 10 | '''Directory structure''' |
| 11 | |
| 12 | On a given volunteer host, each project has a separate '''project directory'''. |
| 13 | All the files for that project - application files, |
| 14 | input files, output files - are stored in the project directory. |
| 15 | |
| 16 | Each job runs in a separate '''slot directory''', |
| 17 | which contains '''links''' to all the files needed by that job |
| 18 | (these are like UNIX symbolic links; since Windows NTFS doesn't support |
| 19 | symbolic links, BOINC implements them as XML files). |
| 20 | The names of the link files are called '''logical names''', |
| 21 | and the files they point to have '''physical names'''. |
| 22 | |
| 23 | The BOINC client expects each application to create a specially-named "finish file" |
| 24 | when it is done; this lets it reliably detect when the application has finished |
| 25 | (rather than, e.g., being killed). |
| 26 | |
| 27 | '''Control and communication''' |
| 28 | |
| 29 | The BOINC client interacts with running applications in two ways: |
| 30 | |
| 31 | * The client tells the application when to suspend, resume, and quit. |
| 32 | * The application tells the client its current CPU time, and when it has checkpointed. |
| 33 | |
| 34 | This communication is implemented using a share-memory structure. |
| 35 | There is a separate shared-memory structure for each running application. |
| 36 | |
| 37 | == The BOINC runtime library == |
| 38 | |
| 39 | Suppose you tried to run an existing, unmodified program under BOINC. |
| 40 | There would be two problems: |
| 41 | |
| 42 | * When the program opens and reads its input files, it would get the contents of the XML link files - not what it expects. Similarly, the output would be written to the wrong directory. |
| 43 | * When the program finishes, it wouldn't create a finish file, so the BOINC client would restart it repeatedly. |
| 44 | * The BOINC client wouldn't know the application's CPU time; it would display zero, and volunteers would be confused. |
| 45 | |
| 46 | The easiest way to solve these problems is to modify your program as follows: |
| 47 | * Add calls to BOINC initialization and finalization routines. |
| 48 | * Precede with fopen() call with a BOINC function that maps logical to physical names. |
| 49 | * Link it with the BOINC runtime library. |
| 50 | |
| 51 | == The BOINC wrapper == |
| 52 | |
| 53 | Suppose you have a program that is difficult or impossible to modify |
| 54 | to use the BOINC runtime library (e.g., source code is not available). |
| 55 | You can run it under BOINC, using the '''BOINC wrapper'''. |
| 56 | The wrapper acts as a main program, |
| 57 | managing communication with the BOINC client, |
| 58 | and running your program as a subprocess. |
| 59 | |
| 60 | == Language alternatives == |
| 61 | |
| 62 | The BOINC runtime library is implemented in C++ |
| 63 | and is easiest to use from C/C++ programs. |
| 64 | However, it also has a FORTRAN binding, |
| 65 | and it is possible to run Java and Lisp programs under BOINC as well. |