diff options
Diffstat (limited to 'glibc/signal/signal_thread.mdwn')
| -rw-r--r-- | glibc/signal/signal_thread.mdwn | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn deleted file mode 100644 index 5341b1ab..00000000 --- a/glibc/signal/signal_thread.mdwn +++ /dev/null @@ -1,100 +0,0 @@ -[[!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. |