Merge branch 'fix-clang-cl-strcasecmp' into 'master'
meson: fix str[n]casecmp detection on clang-cl
Closes #2337
See merge request GNOME/glib!1973
diff --git a/README.win32.md b/README.win32.md
index 2925d3d..17b36ac 100644
--- a/README.win32.md
+++ b/README.win32.md
@@ -161,22 +161,9 @@
English (United States), reboot, and restart the build, and the code should build
normally.
-### Visual Studio 2008 hacks
+### Support for pre-2012 Visual Studio
-- You need to run the following lines from your build directory, to embed the
- manifests that are generated during the build, assuming the built binaries
- are installed to `$(PREFIX)`, after a successful build/installation:
-
-```cmd
-> for /r %f in (*.dll.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f $(PREFIX)\bin\%~nf;2
-> for /r %f in (*.exe.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f $(PREFIX)\bin\%~nf;1
-```
-
-
-- If building for amd64/x86_64/x64, sometimes the compilation of sources may seem to hang, which
- is caused by an optimization issue in the 2008 x64 compiler. You need to use Task Manager to
- remove all running instances of `cl.exe`, which will cause the build process to terminate. Update
- the build flags of the sources that hang on compilation by changing its `"/O2"` flag to `"/O1"`
- in `build.ninja`, and retry the build, where things should continue to build normally. At the
- time of writing, this is needed for compiling `glib/gtestutils.c`, `gio/gsettings.c`,
- `gio/gsettingsschema.c` and `gio/tests/gsubprocess-testprog.c`
+This release of GLib requires at least the Windows 8 SDK in order to be built
+successfully using Visual Studio, which means that it is no longer supported to
+build GLib with Visual Studio 2008 nor 2010. People that still need to use
+Visual Studio 2008 or 2010 should continue to use glib-2.66.x.
diff --git a/glib/gthread-posix.c b/glib/gthread-posix.c
index 2ec50f7..3d69767 100644
--- a/glib/gthread-posix.c
+++ b/glib/gthread-posix.c
@@ -537,10 +537,13 @@
* g_rw_lock_writer_lock:
* @rw_lock: a #GRWLock
*
- * Obtain a write lock on @rw_lock. If any thread already holds
+ * Obtain a write lock on @rw_lock. If another thread currently holds
* a read or write lock on @rw_lock, the current thread will block
* until all other threads have dropped their locks on @rw_lock.
*
+ * Calling g_rw_lock_writer_lock() while the current thread already
+ * owns a read or write lock on @rw_lock leads to undefined behaviour.
+ *
* Since: 2.32
*/
void
@@ -556,8 +559,9 @@
* g_rw_lock_writer_trylock:
* @rw_lock: a #GRWLock
*
- * Tries to obtain a write lock on @rw_lock. If any other thread holds
- * a read or write lock on @rw_lock, it immediately returns %FALSE.
+ * Tries to obtain a write lock on @rw_lock. If another thread
+ * currently holds a read or write lock on @rw_lock, it immediately
+ * returns %FALSE.
* Otherwise it locks @rw_lock and returns %TRUE.
*
* Returns: %TRUE if @rw_lock could be locked
@@ -595,13 +599,19 @@
* @rw_lock: a #GRWLock
*
* Obtain a read lock on @rw_lock. If another thread currently holds
- * the write lock on @rw_lock, the current thread will block. If another thread
- * does not hold the write lock, but is waiting for it, it is implementation
- * defined whether the reader or writer will block. Read locks can be taken
+ * the write lock on @rw_lock, the current thread will block until the
+ * write lock was (held and) released. If another thread does not hold
+ * the write lock, but is waiting for it, it is implementation defined
+ * whether the reader or writer will block. Read locks can be taken
* recursively.
*
- * It is implementation-defined how many threads are allowed to
- * hold read locks on the same lock simultaneously. If the limit is hit,
+ * Calling g_rw_lock_reader_lock() while the current thread already
+ * owns a write lock leads to undefined behaviour. Read locks however
+ * can be taken recursively, in which case you need to make sure to
+ * call g_rw_lock_reader_unlock() the same amount of times.
+ *
+ * It is implementation-defined how many read locks are allowed to be
+ * held on the same lock simultaneously. If the limit is hit,
* or if a deadlock is detected, a critical warning will be emitted.
*
* Since: 2.32
