Linus Torvalds wrote:
> There is no way in _hell_ that the correct way to handle this is by doing
> magic things at execve() time. Stop that NOW!
>
> First off, a program had better be correctly startable even if the
> process that does the execve() is _not_ using the new glibc. If I have an
> old "bash" binary, and that means that I cannot start up new binaries
> correctly, that is BROKEN. It's so incredibly broken that it's scary.
>
> Why not do it the _sane_ way, with a system call in crt0.S instead to set
> up the user_tid if you want it?
I agree with Linus: a set_tid_address() system call should be enough,
and it's clear and simple.
Not just because of old binaries. I want to be able to use the new
threading features _without_ using glibc's pthreads, but using the
non-threading portions of glibc if that is still possible.[*] - and
still be able to fork/exec standard glibc-using programs properly.
Btw, when CLONE_VM is clear, SETTID is useful without the CLEARTID
functionality, for the usual reason of preventing races with signal
handlers which need to know the pid. (It's also useful to use both
flags, of course). It might be better to keep the two flags.
Btw2, instead of a new system call, you could create a new clone flag:
CLONE_SELF. This mean "create all the clonable resources, but install
them in _this_ process instead of creating another process".
For example, clone(CLONE_SELF | CLONE_VM, ...) would cause the current
thread to get a new copy of the file descriptor table, new signal
handler table etc., but it would install those in the current process,
not a new one.
This makes it possible to converted a clone()'d thread into a
fork()'d process, for example.
When you have that, set_tid_address() is simply a combination of
flags: CLONE_SETTID | CLONE_VM | CLONE_FS (etc.). Admittedly, the
list of flags is rather whacky and doesn't work when new sharing flags
are added - and I'm not sure if it's actually useful. But it's a
curious idea, what do you think?
-- Jamie
[*] Perhaps it isn't any more. I recently wanted to call Glibc's
shm_open(), but for no apparent reason that forced pthreads to be
linked in which conflicted with the program's own clone() based
threading. So I ended up using a file in /tmp instead of proper
shared memory.
-
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