GNU Guile 2.1.5 released (beta)

[Andy Wingo]

We are pleased to announce GNU Guile release 2.1.5.

Guile 2.1.5 is the fifth pre-release in what will eventually become the
2.2 release series.  We encourage you to test this release and provide
feedback to address@hidden

This release improves Guile's parallelism and concurrency primitives,
with the goal of providing Guile users with the tools they need to build
custom concurrency and parallelism abstractions that suit their needs.
See the full NEWS below, for details.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
>From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.

Guile 2.1.5 can be installed in parallel with Guile 2.0.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

A more detailed NEWS summary follows these details on how to get the
Guile sources.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.gz   (17MB)
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.xz   (10MB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.gz.sig
  http://alpha.gnu.org/gnu/guile/guile-2.1.5.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the SHA256 checksums:

  53994fbb7d92be9b1abfd93526fd9b41aeafcbeb724bddd829f5408c6cc31534  
guile-2.1.5.tar.gz
  f1194b61aaaabe158aa8ae59cc0f50e20e2796634c7f3223549db61338243e65  
guile-2.1.5.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-2.1.5.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 
FF478FB264DE32EC296725A3DDC0F5358812F8F2

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.15
  Libtool 2.4.6
  Gnulib v0.1-800-g68b6ade
  Makeinfo 6.1


Changes in 2.1.5 (changes since the 2.1.4 alpha release):

* Notable changes
** Lightweight pre-emptive threading primitives

The compiler now inserts special "handle-interrupts" opcodes before each
call, return, and loop back-edge.  This allows the user to interrupt any
computation and to accurately profile code using interrupts.  It used to
be that interrupts were run by calling a C function from the VM; now
interrupt thunks are run directly from the VM.  This allows interrupts
to save a delimited continuation and, if the continuation was
established from the same VM invocation (the usual restriction), that
continuation can then be resumed.  In this way users can implement
lightweight pre-emptive threading facilities.

** with-dynamic-state in VM

Similarly, `with-dynamic-state' no longer recurses out of the VM,
allowing captured delimited continuations that include a
`with-dynamic-state' invocation to be resumed.  This is a precondition
to allow lightweight threading libraries to establish a dynamic state
per thread.

* Performance improvements
** Mutexes are now faster under contention

Guile implements its own mutexes, so that threads that are trying to
acquire a mutex can be interrupted.  These mutexes used to be quite
inefficient when many threads were trying to acquire them, causing many
spurious wakeups and contention.  This has been fixed.

* Incompatible changes
** Threading facilities moved to (ice-9 threads)

It used to be that call-with-new-thread and other threading primitives
were available in the default environment.  This is no longer the case;
they have been moved to (ice-9 threads) instead.  Existing code will not
break, however; we used the deprecation facility to signal a warning
message while also providing these bindings in the root environment for
the duration of the 2.2 series.

** SRFI-18 threads, mutexes, cond vars disjoint from Guile

When we added support for the SRFI-18 threading library in Guile 2.0, we
did so in a way that made SRFI-18 mutexes the same as Guile mutexes.
This was a mistake.  In Guile our goal is to provide basic,
well-thought-out, well-implemented, minimal primitives, on top of which
we can build a variety of opinionated frameworks.  Incorporating SRFI-18
functionality into core Guile caused us to bloat and slow down our core
threading primitives.  Worse, they became very hard to describe; they
did many things, did them poorly, and all that they did was never
adequately specified.

For all of these reasons we have returned to a situation where SRFI-18
concepts are implemented only in the `(srfi srfi-18)' module.  This
means that SRFI-18 threads are built on Guile threads, but aren't the
same as Guile threads; calling Guile `thread?' on a thread no longer
returns true.

We realize this causes inconvenience to users who use both Guile
threading interfaces and SRFI-18 interfaces, and we lament the change --
but we are better off now.  We hope the newly revised "Scheduling"
section in the manual compensates for the headache.

** Remove `lock-mutex' "owner" argument

Mutex owners are a SRFI-18 concept; use SRFI-18 mutexes instead.
Relatedly, `scm_lock_mutex_timed' taking the owner argument is now
deprecated; use `scm_timed_lock_mutex' instead.

** Remove `unlock-mutex' cond var and timeout arguments

It used to be that `unlock-mutex' included `wait-condition-variable'
functionality.  This has been deprecated; use SRFI-18 if you want this
behavior from `mutex-unlock!'.  Relatedly, `scm_unlock_mutex_timed' is
deprecated; use `scm_unlock_mutex' instead.

** Removed `unchecked-unlock' mutex flag

This flag was introduced for internal use by SRFI-18; use SRFI-18
mutexes if you need this behaviour.

** SRFI-18 mutexes no longer recursive

Contrary to specification, SRFI-18 mutexes in Guile were recursive.
This is no longer the case.

** Thread cleanup handlers removed

The `set-thread-cleanup!' and `thread-cleanup' functions that were added
in Guile 2.0 to support cleanup after thread cancellation are no longer
needed, since threads can declare cleanup handlers via `dynamic-wind'.

** Only threads created by Guile are joinable

`join-thread' used to work on "foreign" threads that were not created by
Guile itself, though their join value was always `#f'.  This is no
longer the case; attempting to join a foreign thread will throw an
error.

** Dynamic states capture values, not locations

Dynamic states used to capture the locations of fluid-value
associations.  Capturing the current dynamic state then setting a fluid
would result in a mutation of that captured state.  Now capturing a
dynamic state simply captures the current values, and calling
`with-dynamic-state' copies those values into the Guile virtual machine
instead of aliasing them in a way that could allow them to be mutated in
place.  This change allows Guile's fluid variables to be thread-safe.
To capture the locations of a dynamic state, capture a
`with-dynamic-state' invocation using partial continuations instead.

* New deprecations
** Arbiters deprecated

Arbiters were an experimental mutual exclusion facility from 20 years
ago that didn't survive the test of time.  Use mutexes or atomic boxes
instead.

** User asyncs deprecated

Guile had (and still has) "system asyncs", which are asynchronous
interrupts, and also had this thing called "user asyncs", which was a
trivial unused data structure.  Now that we have deprecated the old
`async', `async-mark', and `run-asyncs' procedures that comprised the
"user async" facility, we have been able to clarify our documentation to
only refer to "asyncs".

** Critical sections deprecated

Critical sections have long been just a fancy way to lock a mutex and
defer asynchronous interrupts.  Instead of SCM_CRITICAL_SECTION_START,
make sure you're in a "scm_dynwind_begin (0)" and use
scm_dynwind_pthread_mutex_lock instead, possibly also with
scm_dynwind_block_asyncs.

** `scm_make_mutex_with_flags' deprecated

Use `scm_make_mutex_with_kind' instead.  See "Mutexes and Condition
Variables" in the manual, for more.

** Dynamic roots deprecated

This was a facility that predated threads, was unused as far as we can
tell, and was never documented.  Still, a grep of your code for
dynamic-root or dynamic_root would not be amiss.

** `make-dynamic-state' deprecated

Use `current-dynamic-state' to get an immutable copy of the current
fluid-value associations.

* Bug fixes
** cancel-thread uses asynchronous interrupts, not pthread_cancel

See "Asyncs" in the manual, for more on asynchronous interrupts.