Report a bug here:
Check this short introductory article about structured concurrency.
The best way to find out is to check for yourself. You will find some small performance benchmarks in the
Generally speaking, though, libdill's concurrency primitives are only a bit slower than basic C flow control statements. A context switch has been seen to execute in as little as 6 ns, with coroutine creation taking 26 ns. Passing a message through a channel takes about 40 ns.
select, is deterministic. If multiple clauses can be executed, the clause closest to the beginning of the pollset wins.
chdonesignals the closing of a channel to both senders and receivers.
libmill was a project that aimed to copy Go's concurrency model to C 1:1 without introducing any innovations or experiments. The project is finished now. It will be maintained but won't change in the future.
libdill is a follow-up project that experiments with structured concurrency and diverges from the Go model.
Technically, these are the differences:
chooseis a function in libdill rather than a language construct, or Go's panic is replaced with error returns.
recvon the channel to return the
EPIPEerror rather than a value.
chdonewill signal both the senders and the receivers of a channel. This allows for scenarios such as multiple senders and a single receiver communicating via a single channel. The receiver can use
chdoneto let the senders know that it's terminating.
fdwaitwas replaced by
fdout. The idea is that if we want data to flow through the connection in both directions in parallel, we should use two coroutines rather than one.
To clone the repository, run:
$ git clone https://github.com/sustrik/libdill.git
To build from the source (you'll need automake and libtool), run:
$ ./autogen.sh $ ./configure $ make $ make check $ sudo make install
For easy debugging, use the following configure options:
$ ./configure --disable-shared --enable-debug --enable-valgrind
The above will turn optimization off, generate debug symbols, and link all the tests with the static version of the library. The second option will cause executables in the
tests subdirectory to be actual debuggable binaries rather that wrapper shell scripts. The last option instructs valgrind about where the coroutine stacks are located, thereby preventing valgrind from generating spurious warnings.
To contribute to libdill, create a GitHub pull request. You have to state that your patch is submitted under the MIT/X11 license, so that it can be incorporated into the mainline codebase without licensing issues.
If you make a substantial contribution to a file, add your copyright to the file header. Irrespective of whether you do so or not, your name will be added to the AUTHORS file to indicate you own copyright to part of the codebase.
$ ./configure --enable-gcov $ make clean $ make check $ lcov -t "libdill" -o libdill.info -c -d . $ genhtml -o lcov libdill.info
After doing the steps above open
lcov/index.html in your browser.
The source for all the man pages is
man/manpages.src. If you want to fix the man pages edit that file.
To generate actual man pages from the source you'll need
pandoc. Do the following:
$ cd man $ ./generate.sh
Generated man pages are added to the git repository so that they are available even for users without the appropriate toolchain installed.
The source for the website is in
website/src directory. The source for man pages is in
To generate the acutal website you'll need
pandoc. Do the following:
$ cd website $ ./generate.sh
Generated HTML pages are added to the git repository so that they are available even for users without the appropriate toolchain installed.
These instructions are intended for project maintainers:
make distcheckto check whether the packaging process still works.
git tag -a 0.3-beta; git push origin 0.3-beta).
./autogen.sh; ./configure; make distcheck).