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/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:25 EST