WSL apps

The WSL wrapper lets you run Linux applications on Windows computers using WSL. BOINC provides a WSL wrapper executable.

The WSL wrapper

• chooses a WSL distro to use
• launches an app in that distro
• monitors the app (e.g. CPU usage) and reports its status to the BOINC client
• monitors process control requests (suspend/resume/abort) from the BOINC client and performs them.

App versions

A WSL app version must include

• The WSL wrapper, marked as the app version's main program.
• A 'control script', the top-level executable that runs in WSL. Its logical name must be main and it must have the <copy_file/> attribute.
• Additional files: data files or 'worker' executables.

Command line args of the WSL wrapper

Optional arguments:

--os_name regexp
--os_version regexp

Use only WSL distros whose OS name and version match the regular expressions.

--pass_thru X

Append X to the command used to run the app's control script (see below). X may specify multiple options, e.g.

--pass_thru '--foo 1 --blah 2'

The control script

The control script 'main' must

• Resolve input and output link files as needed, and connect the resulting paths to worker executables.
• Execute the worker executable(s).

Typically 'main' is a bash or perl script, since those are the languages present in stock WSL distros.

In bash, you can resolve link files with this function:

resolve () {
    sed 's/<soft_link>//; s/<\/soft_link>//' $1 | tr -d '\r\n'
}

This takes a logical file name (the name of a link file) and returns the path of the physical file in the project directory.

For example, suppose your application has a binary with logical name worker that takes input and output filenames as command-line arguments. These files have logical names in and out. The control script might look like:

#! /bin/bash
resolve () {
    sed 's/<soft_link>//; s/<\/soft_link>//' $1 | tr -d '\r\n'
}
$(resolve worker) --nsecs 60 $(resolve in) $(resolve out)

If instead the work reads from stdin and writes to stdout, the command might be

$(resolve worker) --nsecs 60 < $(resolve in) > $(resolve out)

If the job involves several executables run in sequence, the control script might look like

#! /bin/bash
...
if [ ! -f prog1_done ]; then
    prog1; touch prog1_done
fi
if [ ! -f prog2_done ]; then
    prog2; touch prog2_done
fi
...

This prevents rerunning steps that have already been completed.