headers
Albert D. Cahalan | 1 Oct 2002 01:12
Favicon

threads


So a process calls fork() and the child calls fork() and
so on for a bit... and ps is to conclude that all those
processes are threads?

More seriously, you've introduced a gratuitous incompatibility
with AIX and Tru64. Compaq/HP documents -m and m as:

      Prints all threads in a task,
      if the task has more than one.

So you have the switch exactly backwards. There's a whole
world of UNIX-like systems out there. BSD fans already have
much to complain about, including "ps h" and many of top's
options.

Please back this out until a proper implementation is done.
(and yes, it will be done)
Permalink | Reply | 10 comments |
headers
Robert Love | 1 Oct 2002 01:29

Re: threads

On Mon, 2002-09-30 at 19:12, Albert D. Cahalan wrote:

> So a process calls fork() and the child calls fork() and
> so on for a bit... and ps is to conclude that all those
> processes are threads?

Yes, it does.  In all reality how long are those tasks going to sit
around and not touch the address space?

In testing - and bear in mind RedHat is shipping a version of this patch
with 8.0 - I do not see any false-positives.  Sure, we can fork() some
examples and just let them sit there in the same address space... but
aren't those the same process sharing an address space (i.e. they are
"threads") anyhow?

> More seriously, you've introduced a gratuitous incompatibility
> with AIX and Tru64. Compaq/HP documents -m and m as:
> 
>       Prints all threads in a task,
>       if the task has more than one.
> 
> So you have the switch exactly backwards. There's a whole
> world of UNIX-like systems out there. BSD fans already have
> much to complain about, including "ps h" and many of top's
> options.

I'd prefer for the default behavior to be the previous.

I do not care what Compaq says ps(1) should do.  Without this patch the
feature is unsupported so what is the harm?  If it is really a big deal
(Continue reading)

Permalink | Reply | 9 comments |
headers
Albert D. Cahalan | 1 Oct 2002 02:36
Favicon

Re: threads

>> So a process calls fork() and the child calls fork() and
>> so on for a bit... and ps is to conclude that all those
>> processes are threads?
>
> Yes, it does.  In all reality how long are those tasks going to sit
> around and not touch the address space?

Suppose they do pretty much the same thing.

They're starting from the same state. The kernel and C library
can both be damn regular about things. You always get the next
free file descriptor. I don't think the kernel will randomize
what mmap() returns.

>> More seriously, you've introduced a gratuitous incompatibility
>> with AIX and Tru64. Compaq/HP documents -m and m as:
>> 
>>       Prints all threads in a task,
>>       if the task has more than one.
>> 
>> So you have the switch exactly backwards. There's a whole
>> world of UNIX-like systems out there. BSD fans already have
>> much to complain about, including "ps h" and many of top's
>> options.
>
> I'd prefer for the default behavior to be the previous.

That behavior appears to violate several standards.

The "no threads shown" behavior makes for a better user interface.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Robert Love | 1 Oct 2002 03:12

Re: threads

On Mon, 2002-09-30 at 20:36, Albert D. Cahalan wrote:

> Lots of sysadmins do care, for script and human compatibility.
> Please stop using m and -m opposite to what AIX and Tru64 do.
> This is like the "ps -aux" issue, except w/o an alternative that
> works sanely on both kinds of systems.
> 
> How about this for now:
> 
> --threads-apart    the old behavior
> --threads-hidden   sum them up; show only the process
> --threads-grouped  sum them up; show process followed by threads

Have a patch?

> >> Please back this out until a proper implementation is done.
> >> (and yes, it will be done)
> >
> > No, a proper implementation will not come around until everything is
> > using CLONE_THREAD.  When that happens, /proc will not even export the
> > subthreads of the thread group.
> 
> What do you mean, "not even export"?

/proc does not show subthreads of a thread group.

This is because for_each_process() skips subthreads.  All of this is
contingent on using CLONE_THREAD, of course.

> Know where I can find a stable and recent 2.5.xx machine to use?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Larsson | 1 Oct 2002 11:44
Picon
Favicon

Re: threads

On Mon, 30 Sep 2002, Albert D. Cahalan wrote:

> >> So you have the switch exactly backwards. There's a whole
> >> world of UNIX-like systems out there. BSD fans already have
> >> much to complain about, including "ps h" and many of top's
> >> options.
> >
> > I'd prefer for the default behavior to be the previous.
> 
> That behavior appears to violate several standards.
> 
> The "no threads shown" behavior makes for a better user interface.
> The only think bad about it is that some care is required to
> avoid collecting up all processes. (which hurts in the presence
> of overloading or kernel bugs)

For exactly this reason I will revese this behaviour in RH (if I have to, 
I hope you change your mind). We get way to many bugreports by people 
getting confused by threads in the ps listing. This was the main reason I 
wrote the patch for RH 8.0. 

In addition this will be the default behaviour with NTPL (new thread lib), 
because the sub-threads won't be exported in /proc (I believe).

--

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl <at> redhat.com    alla <at> lysator.liu.se 
He's a fast talking crooked matador with a secret. She's a wealthy punk 
mechanic who believes she is the reincarnation of an ancient Egyptian queen.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rik van Riel | 1 Oct 2002 17:30
Picon
Favicon

Re: threads

On Tue, 1 Oct 2002, Alexander Larsson wrote:

> > That behavior appears to violate several standards.
>
> For exactly this reason I will revese this behaviour in RH

> In addition this will be the default behaviour with NTPL (new thread lib),
> because the sub-threads won't be exported in /proc (I believe).

This settles it.  Compatibility, standards compliance and
being the same as the new threading behaviour of the system.

Robert, unless you have a really really good reason why we
should have the old procps behaviour as the default I'd like
to switch to the new behaviour as default.

I promise I'll make sure to document the thing.

regards,

Rik
--

-- 
A: No.
Q: Should I include quotations after my reply?

http://www.surriel.com/		http://distro.conectiva.com/
Permalink | Reply | 5 comments |
headers
Albert D. Cahalan | 1 Oct 2002 18:27
Favicon

Re: threads

> This settles it.  Compatibility, standards compliance and
> being the same as the new threading behaviour of the system.
>
> Robert, unless you have a really really good reason why we
> should have the old procps behaviour as the default I'd like
> to switch to the new behaviour as default.

a. overloaded systems
b. stuck processes (kernel bug)

Sorting is not the default for the above reasons.
The thread hack involves sorting. You gather up
all the processes, using lots of memory as you go.
Meanwhile there's a bloated process that needs to
be killed -- and then thanks to Rik :-) your ps
gets hit by OOM kill.

Besides, why bother? Changing glibc will change
nearly all threaded apps to use CLONE_THREAD.
Problem solved, not a buggy hack, and compatible
with the rest of the world.
Permalink | Reply | 0 comments |
headers
Robert Love | 1 Oct 2002 18:28

Re: threads

On Tue, 2002-10-01 at 11:30, Rik van Riel wrote:

> Robert, unless you have a really really good reason why we
> should have the old procps behaviour as the default I'd like
> to switch to the new behaviour as default.

I still disagree, but I guess that is allowed.

Attached patch makes the default behavior to not show threads in ps(1)
or top(1) and documents the change.  Flag `-m' in ps and key 'H' in top
reverts to the current "show all threads" behavior.

Patch is against current CVS.

	Robert Love
Attachment (procps-show-threads-by-default-rml-2.0.9.20021001-1.patch): text/x-patch, 7379 bytes
Permalink | Reply | 0 comments |
headers
Albert D. Cahalan | 1 Oct 2002 19:03
Favicon

Re: threads

> This settles it.  Compatibility, standards compliance and
> being the same as the new threading behaviour of the system.
> 
> Robert, unless you have a really really good reason why we
> should have the old procps behaviour as the default I'd like
> to switch to the new behaviour as default.

Now that I think about it some more, this is good.
It gets the interface correct. The internals can
be fixed up later.
Permalink | Reply | 2 comments |
headers
Robert Love | 1 Oct 2002 19:07

Re: threads

On Tue, 2002-10-01 at 13:03, Albert D. Cahalan wrote:

> Now that I think about it some more, this is good.
> It gets the interface correct. The internals can
> be fixed up later.

That is what I have been saying all along :)

When CLONE_THREAD is prevalent we can remove this code.  At the same
time we need to add some logic for calculating the subthread information
in case someone passes `-m' anyhow (which will not be all that pretty...
we need to add kernel support for, anyhow).

Rik, please commit the previous patch I sent.  It should make everyone
happy.

	Robert Love
Permalink | Reply | 0 comments |

Gmane