From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- glibc/signal/signal_thread.mdwn | 45 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) (limited to 'glibc') diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn index c6e8d69e..544d387d 100644 --- a/glibc/signal/signal_thread.mdwn +++ b/glibc/signal/signal_thread.mdwn @@ -13,12 +13,11 @@ 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 +[[!tag open_issue_documentation]] + bugs around signals are very tricky signals are actually the most hairy part of the hurd and the reason they're aynchronous is that they're handled by a @@ -50,3 +49,43 @@ other threads. mach and the hurd were intended to be "hyperthreaded" [[open_issues/multithreading]]. + + +# IRC, freenode, #hurd, 2013-09-17 + + I just realized that I know next to nothing about signal + handling on the Hurd... + especially /hurd/inits role in it + reading glibcs kill.c it does not involve /hurd/init at all, but + /hurd/init is full of proxying code for the msg protocol + ah, /hurd/init mitms the signal handling logic in the libc for + its own signals + for msg_sig_post it sends a reply immediately, and then + processes the signal, I wonder why that is done + also it "forwards" any signals it receives to the child it + spawned (like /etc/hurd/runsystem), I wonder why... + good thing the comments tell what is done, not why... + so in theory kill -HUP 1 should have been forwarded to the + "runsystem" process, I wonder why that does not work if that one execs + sysvinit + teythoon: can't help you there :/ + braunr: I think I sorted it out on my own, we'll see how that + works out in practice ;) + good + + +## IRC, freenode, #hurd, 2013-09-18 + + braunr: I figured out why /hurd/init does this strange thing + with the msg protocol + braunr: it has no signal thread + I wonder how /hurd/exec and the initial filesystem handle + this... + err, afaics the signal thread is created in fork(), so any + process not created using it (ie manually using task_create) should lack + the signal thread, no? + that'd be the root fs, /hurd/{exec,init,auth,proc} and + /etc/hurd/runsystem (the child started by /hurd/init) + but I see only /hurd/init doing something about it, namely + setting a msgport and handling the msg protocol, relaying any messages to + the signal handling logic in the glibc -- cgit v1.2.3