Messages in this thread | | | Date | Wed, 29 Mar 2000 10:19:50 -0800 | From | Christopher Smith <> | Subject | Re: Slow pthread_create() under high load |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Mar 28, 2000 at 10:52:49AM -0800, Linus Torvalds wrote: > In article <20000328014126.A2740@xman.org>, > Christopher Smith <x@xman.org> wrote: > I don't understand the pid sharing argument. Just cache the pid of the > parent process, you're done. > > Many UNIX implementations do something like this in their getpid() > routine anyway: > > static pid_t mypid = 0; > > pid_t getpid(void) > { > if (!mypid) > mypid = __getpid(); > return mypid; > } > > They do it because system calls on most UNIXes are quite slow, and > "getpid()" is used by some (bad) benchmarks to test for system call > speed. Doing it for those reasons is bad. > > But the "optimization" in itself is not bad, it's just the _reason_ for > it historically that I dislike. If you take the above code, and add the > code to initialize "mypid" on pthread_create(), then suddenly you have a > (a) faster getpid() (not that it should matter) and (b) it gives you > POSIX behaviour for the subthreads. What's the problem?
The main problem is, assuming this is being done in userland (as you pointed out it's silly to constantly do syscalls to get your PID unless you REALLY expect it to change a lot and it's hard to trap the points where it changes) while internally the application may believe it's all the same PID, to external programs there are still multiple PID's. This is particularly relevant when it comes time to use signals, but I imagine has implications beyond this. > Note that the reason the kernel is not POSIX-compliant is: > - the POSIX standard is technically stupid. It's much better to use a > cleaner fundamental threading model and build on top of that.
I agree. I think so long as the kernel provides a good infrastructure for doing threading, the rest of the problem should be left to userland to deal with. Indeed, if POSIX is really that broken I'd be happy with a well integrated Linux-threading library, with a poorly performing POSIX-threads compatibility library implemented on top of it.
> - things like the above are just so much better and more easily done in > user space anyway.
While true, there are unfortunately system wide issues to threads (such as what I pointed out) which require at least some minimal kernel support to make them possible. I think the kernel's clone() functionality provides almost all, if not all, of what you need. I will look at it more closely (to date I've mostly been looking at the userland interface as that's what I actually care about). > The reason LinuxThreads has a hard time becoming POSIX-compliant is that > I refuse to apply stupid patches, and a lot of the patches sent to me > have been frankly stupid. They've often implemented pthreads > functionality without any actual thought of how it _could_ be done more > cleanly with a user/kernel split. Again, see above.
Ok. I didn't know this angle. I had always thought of pthreads as being a user/kernel split in the first place (indeed, I think the standard was defined with that concept in mind). So perhaps LinuxThreads could be made into a high-performance POSIX compliant (or more accurately MORE POSIX compliant) library if some more effort was spent on getting it right. > Anyway, check out the netscape/mozilla threading library, and the one > from Apache (which I think is based on the mozilla one). They may just > fit your needs..
I've looked at the Apache stuff and it's all POSIX based, but I will take a look at the NSPR stuff. Thanks for the suggestion.
- --Chris
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE44klCfrrCpthD+UYRAtTgAKChmqLwa9DV5i8P4VBzHsNdObpqmQCgzGwB F1mvuHxt6XOg0/MKZ/Pm8r4= =sqSF -----END PGP SIGNATURE-----
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |