From ed7d94d989c92edb3b64c09db0759ec1ece6f114 Mon Sep 17 00:00:00 2001
From: Matthew Dillon <dillon@dragonflybsd.org>
Date: Mon, 23 Jul 2007 23:04:21 +0000
Subject: [PATCH] Clarify two usage cases for umtx.2

---
 lib/libc/sys/umtx.2 | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/libc/sys/umtx.2 b/lib/libc/sys/umtx.2
index 3683490ff..52b1a084f 100644
--- a/lib/libc/sys/umtx.2
+++ b/lib/libc/sys/umtx.2
@@ -30,7 +30,7 @@
 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.\" $DragonFly: src/lib/libc/sys/umtx.2,v 1.10 2007/06/30 19:03:52 swildner Exp $
+.\" $DragonFly: src/lib/libc/sys/umtx.2,v 1.11 2007/07/23 23:04:21 dillon Exp $
 .\"
 .Dd February 21, 2005
 .Dt UMTX 2
@@ -83,11 +83,15 @@ Kernel support for userland mutexes is based on the physical memory backing
 the user address.  Two userland programs may use this facility through
 .Fn mmap ,
 .Fn sysv ,
-and
-.Fn rfork
-based shared memory.  It is important to note that the kernel does not
+.Fn rfork ,
+or light weight process-based shared memory.
+It is important to note that the kernel does not
 take responsibility for adjusting the contents of the mutex or for the
 userland implementation of the mutex.
+.Pp
+.Fn umtx_sleep
+does not restart in case of a signal, even if the signal specifies
+that system calls should restart.
 .Sh RETURN VALUES
 .Fn umtx_sleep
 will return 0 if it successfully slept and was then woken up.  Otherwise
-- 
2.11.4.GIT