summaryrefslogtreecommitdiff
path: root/glibc/signal/signal_thread.mdwn
blob: c6e8d69e6ab64ff5222e4103e00125a40bed164f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

For delivering a signal, Mach forwards an `msg_sig_post` message from the
invoker of `kill` to the target process.  The target process' [[signal_thread]]
job is it to listen to such messages and to set up signal handler contexts in
other threads.

---

[[!tag open_issue_documentation]]

# IRC, freenode, #hurd, 2011-04-20

    <braunr> bugs around signals are very tricky
    <braunr> signals are actually the most hairy part of the hurd
    <braunr> and the reason they're aynchronous is that they're handled by a
      second thread
    <braunr> (so yes, every process on the hurd has at least two threads)
    <svante_> braunr: How to solve the asynch problem then if every process has
      two threads?
    <braunr> the easiest method would be to align ourselves on what most other
      Unices do
    <braunr> establish a "signal protocol" between kernel and userspace
    <braunr> with a set of signal info in a table, most likely at the top of
      the stack
    <braunr> but this is explicitely what the original Mach developers didn't
      want, and they were right IMO
    <braunr> having two threads is very clean, but it creates incompatibilites
      with what POSIX requires
    <braunr> so there might be a radical choice to make here
    <braunr> and i doubt we have the resources to make it happen
    <svante_> What is the advantage of having two threads per process, a per
      the original design?
    <braunr> it's clean
    <braunr> you don't have to define async-signal-safe functions
    <braunr> it's like using sigwait() yourself in a separate thread, or
      multiplexing them through signalfd()
    <svante_> Regardless of the advantages, isn't two threads per process a
      waste of resources?
    <braunr> sure it is
    <braunr> but does it really matter ?
    <braunr> mach and the hurd were intended to be "hyperthreaded"

[[open_issues/multithreading]].