Messages in this thread | | | Date | Mon, 23 Sep 2002 21:59:22 +0200 | Subject | Re: [ANNOUNCE] Native POSIX Thread Library 0.1 | From | Peter Waechtler <> |
| |
Am Montag den, 23. September 2002, um 17:30, schrieb Larry McVoy:
>>> Instead of taking the traditional "we've screwed up the normal system >>> primitives so we'll event new lightweight ones" try this: >>> >>> We depend on the system primitives to not be broken or slow. >>> >>> If that's a true statement, and in Linux it tends to be far more true >>> than other operating systems, then there is no reason to have M:N. >> >> No matter how fast you do context switch in and out of kernel and a >> sched >> to see what runs next, it can't be done as fast as it can be avoided. > > You are arguing about how many angels can dance on the head of a pin. > Sure, there are lotso benchmarks which show how fast user level threads > can context switch amongst each other and it is always faster than going > into the kernel. So what? What do you think causes a context switch in > a threaded program? What? Could it be blocking on I/O? Like 99.999% > of the time? And doesn't that mean you already went into the kernel to > see if the I/O was ready? And doesn't that mean that in all the real > world applications they are already doing all the work you are arguing > to avoid?
Getting into kernel is not the same as a context switch. Return EAGAIN or EWOULDBLOCK is definetly _not_ causing a context switch.
Is sys_getpid() causing a context switch? Unlikely Do you know what blocking IO means? M:N is about to avoid blocking IO!
- 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/
| |