On Tue, Mar 06, 2001 at 05:28:43PM +0100, Jorge David Ortiz Fuentes wrote:
[snip]
> "task" that can be run. Using this structure makes easier to identify
> which threads belong to the same process and tools such as ps or top
> show the TID as a field.
>
> I understand that changing this in the Linux kernel would mean that:
> * some tools will have to be modified.
> * the proc filesystem should create a directory using the TID instead
> of the PID.
> * some features as VM handling, signaling or exec()ing from a thread
> would be more difficult to implement.
> * compatibility will be broken.
>
> However, I miss some way to indicate that two processes are, in
> fact, threads of the same process. Maybe there is something I'm
> missing. Let me elaborate this.
[snip]
> This information is missleading since there is no way to know that
> these 9 threads are sharing memory. If you run 'ps axl' you can see
> the hierarchy as if it was a multiprocess program, i.e. no difference
> to show you that they are threads. Not even reading
> /proc/<pid>/status you get info about these being threads.
[snip]
There are no threads in Linux.
All tasks are processes.
Processes can share any or none of a vast set of resources.
When processes share a certain set of resources, they have the same
characteristics as threads under other OSes (except the huge performance
improvements, Linux processes are already as fast as threads on other OSes).
Execution contexts which share resources do not have to share memory. If we
implemented top to aggregate such processes (as you suggest), the result
would also be potentially misleading.
If we were to break compatibility it should be actually fix the situation,
not replace once misleading situation with another.
Sometimes it is handy to view a collection of execution contexts as a
singular object. However, such is also the case with a service implemented
as a collection of share-none standard unix processes (like postfix). A
better solution would be a more generalized system for service object
management. Such a solution could likely be implemented without kernel
intervention (though perhaps a general facility to determine what shares what
with who might be needed).
-
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 : Wed Mar 07 2001 - 21:00:20 EST