Table of Contents
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.