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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
[[!meta copyright="Copyright © 2011 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]]
<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"
<braunr> so basically, a thread should consume only a few kernel resources
<braunr> in GNU Mach, it doesn't even consume a kernel stack because only
continuations are used
<braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table
entries, and almost no CPU time
<svante_> What does "hyperthreaded" mean: Do you have a reference?
<braunr> in this context, it just means there are a lot of threads
<braunr> even back in the 90s, the expected number of threads could scale
up to the thousand
<braunr> today, it isn't much impressive any more
<braunr> but at the time, most systems didn't have LWPs yet
<braunr> and a process was very expensive
<svante_> Looks like I have some catching up to do: What is "continuations"
and LWP? Maybe I also need a reference to an overview on multi-threading.
<ArneBab> Lightweight process?
http://en.wikipedia.org/wiki/Light-weight_process
<braunr> svante_: that's a whole computer science domain of its own
<braunr> yes
<braunr> LWPs are another names for kernel threads usually
<braunr> continuations are a facility which allows a thread to store its
state, yield the processor to another thread, and when it's dispatched
again by the scheduler, it can resume with its saved state
<braunr> most current kernels support kernel preemption though
<braunr> which means their state is saved based on scheduler decisions
<braunr> unlike continuations where the thread voluntarily saves its state
<braunr> if you only have continuations, you can't have kernel preemption,
but you end up with one kernel stack per processor
<braunr> while the other model allows kernel preemption and requires one
kernel stack per thread
<svante_> I know resources are limited, but it looks like kernel preemption
would be nice to have. Is that too much for a GSoC student?
<braunr> it would require a lot of changes in obscure and sensitive parts
of the kernel
<braunr> and no, kernel preemption is something we don't actually need
<braunr> even current debian linux kernels are built without kernel
preemption
<braunr> and considering mach has hard limitations on its physical memory
management, increasing the amount of memory used for kernel stacks would
imply less available memory for the rest of the system
<svante_> Are these hard limits in mach difficult to change?
<braunr> yes
<braunr> consider mach difficult to change
<braunr> that's actually one of the goals of my stalled project
<braunr> which I hope to resume by the end of the year :/
<svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other
threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread
sharing resources and in SunOS they are "user threads". Which is closest
for Hurd?
<braunr> i told you
<braunr> 14:09 < braunr> LWPs are another names for kernel threads usually
<svante_> Similar to to the IBM definition then? Sorry for not remembering
what I've been reading.
|
