Messages in this thread | | | Subject | Re: Better CLONE_SETTLS support for Hammer | From | Andi Kleen <> | Date | 06 Mar 2003 20:09:16 +0100 |
| |
On Thu, 2003-03-06 at 19:58, Ulrich Drepper wrote:
> > 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/
| |