Linus Torvalds wrote: > I do not see the point of associating keys with signal state. > > And it _is_ signal state, even if some people mistakenly think that it's > about "processes". Linux still hasn't fallen into the trap of believing > that POSIX threads are somehow magical and the only way to do things.
Erm... Even if it's you who suggested it? To quote: | Also, if it's shared on CLONE_THREAD, then logically the structure already | exists: it is "tsk->signal". The _naming_ may be historical and slightly | confusing, but the fact is, that's the structure that gets shared on | CLONE_THREAD, and there's no technical point to creating a new one. | | If the name really bothers you, I'd be more willing to rename | "tsk->signal", although the pain of that makes me strongly suspect it's | not worth it. Well, I've come up with a patch to do the renaming; whilst it is quite invasive, if it's applied as soon as possible after 2.6.11 is out, it shouldn't cause too much of a problem. I can even make the changes in stages to have less impact on the drivers. Also, _why_ can't signal_struct be changed into something associated with a thread group? So it contains the controls for thread-group-wide signalling? But that's okay - the struct would then be for thread-group-wide concepts, and so it would still fit. > The kernel very much believes in various shared resources. Signal state > (tty, resource limits, and actual signals handlers) is one such shared > thing, but so is VM state, file table state etc etc. Why would keys > logically be associated with signals, and not with the file table, for > example? Or the VM? Or just per-thread? Because I want to have the session- and process-keyrings associated with each process to be shared amongst all the threads that process contains, such that if one thread joins a new session this affects all its sibling threads too. And in this context, I think 'threads' have to be defined by CLONE_THREAD. Why else have such a clone flag? Or does CLONE_THREAD not "distinguish" threads and processes as far as /proc, exec and exit are concerned? There's a per-thread keyring available too; and that is strictly per thread. > In other words, what does this buy us, if anything? From a logical > standpoint, I'd have said that it makes more sense to associate this with > the filesystem information, since keys would tend to mostly go together > with the notion of permissions on file descriptors. Just like uids, gids and group lists, eh? I think keys are more comparable to those than to permissions masks. Besides, from a logical standpoint, I generally think of a "process" as being the concept to which threads, fds, VMs, etc can be attached. Obviously Linux is more flexible than that, but I nonetheless find it easier to explain the semantics to people in terms of processes and threads. > Making keys be associated with signals just doesn't seem to make any > sense. Then redefine the signal_struct structure. There's no particular reason it can't be made into the "anchor" block for a thread group, and I can see a number of advantages from doing so. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
