You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2005/06/16 13:25:55 UTC
[PATCH] vformatter support for formatting apr_os_thread_t in hex
This uses format %pt. (%pT is existing, and results in tid in
decimal.) The display will use lower-case a-f.
Comments/concerns?
I have a small itch for APR_PID_T_HEX_FMT as well.
My understanding is that this feature can go in trunk because trunk
isn't a released version yet, and it can go in 0.9.x because that is <
1.0 and not covered by the versioning guidelines (other than binary
compatibility), but 1.0 and 1.1 are feature-frozen.
Re: [PATCH] vformatter support for formatting apr_os_thread_t in hex
Posted by Jeff Trawick <tr...@gmail.com>.
On 6/16/05, Joe Orton <jo...@redhat.com> wrote:
> On Thu, Jun 16, 2005 at 07:25:55AM -0400, Jeff Trawick wrote:
> > This uses format %pt. (%pT is existing, and results in tid in
> > decimal.) The display will use lower-case a-f.
> >
> > Comments/concerns?
>
> Seems fine.
>
> [it would be nice if %pT actually printed the thread id with NPTL rather
> than just a pointer value, hmmm]
IOW, look into the opaque value to find something like 1, 2, 3, 4, 5, etc.?
That would be nice. OTOH, that would likely break the ability to
correlate thread ids among logs/displays which used apr thread id
formatting and logs/displays which formatted it directly. Hosed for
some uses either way.
Use a different format character to try to pretty-print the thread id?
Re: [PATCH] vformatter support for formatting apr_os_thread_t in hex
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jun 16, 2005 at 07:25:55AM -0400, Jeff Trawick wrote:
> This uses format %pt. (%pT is existing, and results in tid in
> decimal.) The display will use lower-case a-f.
>
> Comments/concerns?
Seems fine.
[it would be nice if %pT actually printed the thread id with NPTL rather
than just a pointer value, hmmm]
> I have a small itch for APR_PID_T_HEX_FMT as well.
>
> My understanding is that this feature can go in trunk because trunk
> isn't a released version yet, and it can go in 0.9.x because that is <
> 1.0 and not covered by the versioning guidelines (other than binary
> compatibility), but 1.0 and 1.1 are feature-frozen.
Yes, correct. It can't be in a patch release because it's essentially a
new interface (or a new "interface-within-an-interface" perhaps ;).
joe