-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Mar 30, 2000 at 04:13:24AM -0500, Albert D. Cahalan wrote:
> I don't think "unique VM's" is right for Linux. Tasks that share
> files are related just as much as those that share memory.
If you are referring to sharing file handles, then I have to disagree
quite strongly with you here. Every UNIX implementation as well as the
POSIX standard makers would also have to disagree. There's a reason
why a unix pid refers to a unique VM.
> Would you accept a patch that exposed identifiers for every
> shareable part of a task? (kernel pointer values would work)
> Example: a group of 8 related tasks might have 5 address
> spaces total, which "ps" must use to determine total memory.
That sounds kind of neat, but it seems like it would impose a lot of
overhead, and I'm not sure what the benefit is. If two processes are
the result of a fork sharing file handles, what does that really tell
me about them?
> Would you accept a patch that, for any group of related tasks,
> prevented reuse of the initial PID by an unrelated task?
> While a well-behaved thread package would not let the initial
> task exit early, an evil thread package may well seek to
> confuse the system administrator.
IMHO the kernel should be assigning thread-id's which are unique
within their pid. A sys-admin would normally doesn't try to isolate
specific threads anyway, it's enough to know, "one of the threads in
this process is sucking up all the CPU cycles it can take". Process
level information is all you need to know.
> Would you accept a patch that implemented this ability by adding
> a second kill() system call, perhaps with a scope flag?
This makes sense, but I'd think it'd be fine just to have one that's
kill_by_pid and another that's kill_by_tid. Having scoping controls
beyond that seems needlessly complex.
> Would you accept a patch that allowed kill-by-XID, so that the
> PID wrap-around race condition would be eliminated? This could
> be unrelated to the above, or it could be just a different scope.
This seems like solving the problem backwards. If you want to avoid
the PID wrap-around problem, why not make PID wider rather than
introducing an entirely new field which happens to be wider?
- --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/>
iD8DBQE448HjfrrCpthD+UYRAupOAJ9C5ompJyD91XwDjZeBCX87tmRdDwCfbVT6
E+ylvs2J0d/yAAlWsYX/gPU=
=JsfC
-----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:27 EST