> Primarily your point 2, that is, CLONE_PID is supposed to be the flag
> that indicates when a set of tasks (at least) share a common signal
> delivery queue.
I'd like to avoid putting that in CLONE_PID. The clone() syscall so
far decomposes its features into these CLONE_* flags, with fork at one
extreme and "create a thread" at the other (and the things in between
potentially useful). It wouldn't fit in with this to put "everything
else needed for threads" into CLONE_PID.
The one thing a completed CLONE_PID should definitely do is create a
process with some kind of pid:tid process id arrangement, sharing the
pid with the parent, hence the name. It is this feature I don't see
the purpose of (though I'm not claiming it is a bad thing in itself).
Certainly the kernel needs additions to allow for a complete efficient
implementation of POSIX threads. But it would be more in line with the
current interface to break the additions down into CLONE_*
flags. (Though see below)
> It may imply other things, such as the effect of exit. Currently this
> is handled with some particularly ugly atexit hooks; it would be nice
> for things to be done cleaner.
In glibc, it is probably better to think of this as part of the
implementation of exit(), rather than an atexit hook -- it happens to
be implemented as an atexit hook, but that can be changed if it starts
to cause problems.
With the kernel additions need for efficient pthread_create(), the
atexit() hook can probably go away. It would cause some small
application-visible changes, but I think the POSIX spec would allow
it.
Andi Kleen <ak@muc.de> writes:
> Another thing it should do is to broadcast all uid/gid/euid etc. changes
> to all other threads that share the pid. Currently Linux has "per thread
> permissions", that differs from all other Unixes I know and it is a
> potential security problem.
This feature is needed, but it can be done with a CLONE_PERM flag, as
suggested by Olaf earlier in this thread.
There are good reasons not to go too far is breaking features down
into clone flags. If flags are added that are not cleanly orthogonal
(i.e. they ineract in complicated ways) then they will be harder to
implement and debug. I suspect that a distinct CLONE_SIGNAL would
suffer from this.
-- Dave Wragg
- 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.altern.org/andrebalsa/doc/lkml-faq.html