Messages in this thread | | | Date | Sat, 5 Jul 2003 18:06:32 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH 2.5.73] Signal stack fixes #1 introduce PF_SS_ACTIVE |
| |
Jörn Engel wrote: > > It is entirely possible that they do not do this out of signal handlers, > > since that has its own set of problems anyway, and one of the reasons for > > doing co-operative user level threading is to not need locking, and thus > > you never want to do any thread switching asynchronously (eg from a signal > > context).
longjmp() out of signal handlers has a fine tradition, not just for threading but also code written for systems where SIGCLD doesn't interrupt select(), to pick a real example. Admittedly such code doesn't have to be written that way on Linux, but it does exist and has been run on Linux. I doubt such code ever uses sigaltstack().
About co-operative threading: one of the points is that the locks are cheaper, and it's possible for a thread to disable/enable pre-emption very fast, with no system calls or locked memory cycles. In that environment, longjmp() or setcontext() out of timer signals makes sense.
Many years ago I looked at a paper about fixups from signal handlers, an ML run-time environment on SunOS I think, and they decided that longjmp() from the handler was not a reliable strategy. What they did instead was to change the instruction pointer in the sigcontext, and return from the handler. This works on Linux too, but there are two disadvantages: 1. two system calls instead of one (which is an issue when these are a high rate of SIGSEGVs for memory management); 2. the code is necessarily architecture specific, whereas longjmp() from timer signals is relatively portable.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |