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 'main script', the top-level executable (binary or script) 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

Usage:

wsl_wrapper [options] arg1 arg2 ...

Options:

--os_name_regexp regexp
--os_version_regexp regexp

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

Additional cmdline arguments (arg1 ...) will be passed on the command line of main script.

The main script

The 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.