mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-23 17:53:37 +08:00
hurd: Document how EINTR should be handled in critical sections
* hurd/hurd/signal.h (_hurd_critical_section_lock): Document how EINTR should be handled.
This commit is contained in:
parent
477e739b32
commit
e87d8ada29
@ -1,3 +1,8 @@
|
||||
2019-03-16 Samuel Thibault <samuel.thibault@ens-lyon.org>
|
||||
|
||||
* hurd/hurd/signal.h (_hurd_critical_section_lock): Document how EINTR
|
||||
should be handled.
|
||||
|
||||
2019-03-15 Joseph Myers <joseph@codesourcery.com>
|
||||
|
||||
* sysdeps/unix/sysv/linux/syscall-names.list: Update kernel
|
||||
|
@ -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);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user