Messages in this thread |  | | Date | Mon, 28 Aug 2000 20:19:58 +0200 | From | "Andi Kleen" <> | Subject | Re: SCO: "thread creation is about a thousand times faster than |
| |
On Mon, Aug 28, 2000 at 01:03:58PM -0400, Theodore Y. Ts'o wrote: > Date: Sun, 27 Aug 2000 22:36:46 -0500 (CDT) > From: Dave McCracken <dcm@mccr.org> > > I'll also admit signals were always a mess. They never fit very well > with pthreads, and we pretty much punted in the early drafts. I > added sigwait() to the original draft as a way an application could > direct all its signal handling to a single synchronous 'signal > handler' thread, but it never addressed the larger question of how to > make signals and threads play together. > > I'll note that signals is one of the priamry places where Linuxthreads > aren't compatible with Posix threads, and most of the various attempts > to fix this involved kernel hacks that would have penelized the > performance of the kernel in general, not just when dealing with Posix > brain damage. (In one case, I believe the estimates were that it would > slow signal delivery time by a factor of six.)
That must have been a particularly bad idea, the proposals were usually in the range of a few ifs and 2-3 additional cache line references in signal delivery.
[BTW, just by teaching all x86 glibcs to use sa_restorer properly you'll save many more cycles than even a bad posix signal emulation could eat up -- -- the self modifying trampoline is deadly on modern CPUs]
> (And we haven't even gotten to pthread_cancel yet....)
That was unfair ;)
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |