[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Guile-commits] 24/24: Update NEWS.

From: Andy Wingo
Subject: [Guile-commits] 24/24: Update NEWS.
Date: Sun, 6 Nov 2016 18:00:46 +0000 (UTC)

wingo pushed a commit to branch master
in repository guile.

commit f8de9808ed6e8c16f20ba5abd803ecb437138a54
Author: Andy Wingo <address@hidden>
Date:   Sun Nov 6 19:00:29 2016 +0100

    Update NEWS.
    * NEWS: Update.
 NEWS |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/NEWS b/NEWS
index 7233d2f..9221739 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,52 @@ break, however; we used the deprecation facility to signal a 
 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
@@ -51,6 +97,11 @@ make sure you're in a "scm_dynwind_begin (0)" and use
 scm_dynwind_pthread_mutex_lock instead, possibly also with
+** `scm_make_mutex_with_flags' deprecated
+Use `scm_make_mutex_with_kind' instead.  See "Mutexes and Condition
+Variables" in the manual, for more.
 * Bug fixes
 ** cancel-thread uses asynchronous interrupts, not pthread_cancel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]