-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
> This patch is crap, or at least needs a ton more explanation about why you
> would do something that looks quite this horrible and stupid.
Let me explani the use. Sorry for all the confusion. I left Ingo last
night in a state where he didn't have all the info.
The facts:
- - the settid syscall isn't used and is not needed anywhere in libc.so
- - it is only used in the init code of the new libpthread
I.e., all applications but those which are using the new thread code are
unaffected. No special exec handling. Set time, when the setid call is
executed, is early enough: it is the very first thing a multi-threaded
application does. It is the first constructor which is run. Always and
guaranteed.
The *alternatives* to this is a special whacky way to tell exec to do
this. I've no idea how this could be implemented at user level since
the registered address is at least in my code not known at link time.
So this is one of these rare situations where Linus and I actually agree
on something. The settid syscall is not used for exec but instead to
prevent modifying exec.
On to the second part: the clone() change is necessary for situations
where the CLONE_VM bit isn't set (to implement fork()). Using the
CLONE_SETTID flag nevertheless would mean a data structure in the parent
process would be affected. This isn't correct. The data structure
which has to be modified is still in use in the parent. That's the
whole point of fork(), the child inherits the same environment and might
on its own create more threads. I.e., the internals of the thread
library must be intact.
With the proposed change the TID is only written to the child's VM.
This is the right semantics since the child is the one which gets
notified in the end and which might get a signal delivered before it had
the chance to set the TID on its own. This one change saved us from the
mess this could potentially create plus it saves a system call.
And please note: how many normal application (not MT) are calling
getpid() first thing after fork()? With this patch it can be avoided.
Not a big win but it rectifies an IMO not too well designed since
asymmetric interface.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE91+gb2ijCOnn/RHQRAluVAJ9nZB5/w3MImWbVKXS+nw05W+pfQACgzg/d
BsbD+2ff+BaRiDkbHhu1/9w=
=hnJQ
-----END PGP SIGNATURE-----
-
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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:19 EST