[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hpux-devtools
Subject:    Re: HPUX-DEVTOOLS: pstack enhancement requests
From:       Stan Sieler <sieler () allegro ! com>
Date:       2006-09-22 6:02:02
Message-ID: 20060922060202.B79FC5246B3 () opus ! allegro ! com
[Download RAW message or body]

Re:

> >Enhancement requests for pstack:
> 
> You should contact the response center with your suggestions.

Probably ... but posting here allows other developers to say
"hey, yeah...I want that .. and I also want <x>".

Also, the pstack developer might be on this list and see the 
post and be able to ask questions immediately (as happened when I
posted a long list of enhancement requests for ARIES).
 
> >     but, isn't printing your own stack a very common use?
> 
> That's what U_STACK_TRACE or a debugger is for.  I'm not sure anyone
> thought of this use.

But, as we know (the genesis of this thread :), those either don't 
stack trace all threads (U_STACK_TRACE), or might not be available (debugger).
 
> >  2) make pstack able to trace more (kinds of?) processes
> 
> I doubt this can be fixed.  pstack is user space, not part of the kernel.

It's probably work in ttrace(), not pstack.
Still...
 
> >   5) provide a "filter" program feature
> >        pstack -filter "head -20" 1813 
> 
> You want pstack to get in and out and not delay things.  And the whole
> purpose of Unix is to use another tool to customize things.

Precisely ... that's why I want to be able to pass the tool to pstack.
Without that ability, the user has to capture the output, parse it to
separate the individual thread stacktraces, and then run their tool over
each trace individually.  Wow...a lot of non-Unix-style work, which could
be replaced by a Unix-style "here's a filter to use" :)
 
> >   6) provide a means of directing the output to a set of disk files
> Stan Sieler
> 
> Again extra stuff that scripting can provide.

Uh, it's hard to do reliable scripting breaking up a stream of output
based on *potential* output ... the right place to break this kind of
output is precisely where it's *already broken apart within pstack*.

I.e., pstack already has to iteratively handle each thread separately.

> Also, pstack may be a standard and adding this extra stuff may cause
> portability issues.

Hardly ... adding extra features, and then campaigning to get them
adopted as standard is the way ... the only way ... that Unix
can grows.

HP has sat behind the "we can't change a standard" line FAR too long,
and incompletely (imagine a rather wide person trying to hide behind
a skinny tree :)
I.e., HP adds/extents when *it* wants to, but not when *users* ask.

With the untimely demise of the HP 3000, a bunch of rowdy, well-educated,
stubborn users and developers are moving to other platforms ... 
and demanding that they be improved to begin to approach MPE's power :)

Dennis ... you should know from experience that my enhancement suggestions
are usually *very* good ones :)

-- 
Stan Sieler
work:     www.allegro.com
personal: www.sieler.com/wanted/index.html  
 _________________________________________________________________
 To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
    with the message UNSUBSCRIBE hpux-devtools
 _________________________________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]