>
> It's already part of the documented ABI. Yes, if right now somebody
> said r11 or whatever is declared the thread register, we could change
> it. But give it a few more weeks and it'll probably be impossible
It's already pretty much impossible.
> You don't understand threads. There is nothing broken or NPTL-specific
> about the design. Every thread creation mechanism must be signal save.
> LinuxThreads's is not, which is a bit less of a problem since the
> signal handling is broken, too, and signals are unlikely to arrive at
> the new thread. Nevertheless, there are certainly spurious crashes which
> are hard to reproduce and explain which can be attributed to this problem.
I would have designed it with CLONE_BLOCKALLSIGNALS and then set it in
the target process before unblocking signals. This would be in the
spirit of fork/exec and also what posix APIs do for similar
problems (like pselect)
But of course it's too late now. We'll have to live with this
ugly thing.
Just hope you won't run out of the argument registers for the next
round of enhancements ;)
-Andi
-
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/