commit-hurd
[Top][All Lists]
Advanced

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

[hurd, commited] hurd: Document how EINTR should be handled in critical


From: Samuel Thibault
Subject: [hurd, commited] hurd: Document how EINTR should be handled in critical sections
Date: Sat, 16 Mar 2019 19:43:36 +0100

        * hurd/hurd/signal.h (_hurd_critical_section_lock): Document how EINTR
        should be handled.
---
 ChangeLog          | 5 +++++
 hurd/hurd/signal.h | 8 +++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 3d2bdc8143..ce14d885b2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2019-03-16  Samuel Thibault  <address@hidden>
+
+       * hurd/hurd/signal.h (_hurd_critical_section_lock): Document how EINTR
+       should be handled.
+
 2019-03-15  Joseph Myers  <address@hidden>
 
        * sysdeps/unix/sysv/linux/syscall-names.list: Update kernel
diff --git a/hurd/hurd/signal.h b/hurd/hurd/signal.h
index c30f536436..b0b53668d2 100644
--- a/hurd/hurd/signal.h
+++ b/hurd/hurd/signal.h
@@ -168,7 +168,13 @@ extern int _hurd_core_limit;
    A critical section is a section of code which cannot safely be interrupted
    to run a signal handler; for example, code that holds any lock cannot be
    interrupted lest the signal handler try to take the same lock and
-   deadlock result.  */
+   deadlock result.
+
+   As a consequence, a critical section will see its RPCs return EINTR, even if
+   SA_RESTART is set!  In that case, the critical section should be left, so
+   that the handler can run, and the whole critical section be tried again, to
+   avoid unexpectingly exposing EINTR to the application.
+   */
 
 extern void *_hurd_critical_section_lock (void);
 
-- 
2.20.1




reply via email to

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