[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [hurd, commited] hurd: Document how EINTR should be handled in critical sections,
Samuel Thibault <=