-----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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:25 EST