Date: Thu, 12 May 2005 19:40:15 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Jonathan Noack <noackjr@alumni.rice.edu> Cc: freebsd-stable@freebsd.org Subject: Re: Strange top(1) output Message-ID: <20050512164015.GA42110@orion.daedalusnetworks.priv> In-Reply-To: <42836B8F.607@alumni.rice.edu> References: <c21e92e20505100316667e6bd4@mail.gmail.com> <1115815807.8809.3.camel@buffy.york.ac.uk> <20050512103929.GB1320@orion.daedalusnetworks.priv> <200505121349.31508.dom@goodforbusiness.co.uk> <20050512131219.GB3107@orion.daedalusnetworks.priv> <42836B8F.607@alumni.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-05-12 09:43, Jonathan Noack <noackjr@alumni.rice.edu> wrote: >On 5/12/2005 8:12 AM, Giorgos Keramidas wrote: >>On 2005-05-12 13:49, Dominic Marks <dom@goodforbusiness.co.uk> wrote: >>>> + When the view is toggled between processes/threads, the NTHR part >>>> becomes the thread ID of the particular thread. >>> >>> Okay, not really sure what this will look like to me but no need to >>> explain I'll wait until they hit -CURRENT and see for myself. >> >> Instead of displaying a single named/7 line, which would mean that >> there is a named process with 7 threads, in "thread mode" you would >> see 7 lines with named/0, named/1, named/2, ... which would be the >> thread IDs of the distinct threads. > > What happens if the command is long enough to overrun the screen? Is > the thread information truncated and lost? I believe this was the > argument for making a separate column for the thread info. By removing the THR column and merging CPU into WCPU we gain a lot of columns, so I'm hoping that it would be ok to trim the command name in favor of the thread count. Before actually having something in the form of a patchfile though it's hard to tell if it's going to be good or not. - Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050512164015.GA42110>