Re: [PATCH] InstanceId

On Wed, 29 Sep 2010 12:20:23 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> Added InstanceId to uniquely identify concurrent messages, transactions,

> etc.
>
> Use InstanceId for async job and calls identification.
>
> Side-effect: removes inconsistent prefixes for job debugging: ecapxN,
> icapxN, asyncN are now all jobN, simplifying searching and processing
> debugging logs.
>
> -----------
>
> We have a few classes that use mostly unique identifiers for debugging.
> More are coming, including MemBlob from the StringNG branch and IPC
> messages used by SMP code. The classes I know about benefit from having
> sequentially increasing IDs, specific to the class. For example, it is
> very convenient to have async jobs numbered 1,2,3,4,... because it often

> preserves the job number during repetitive debugging and also shows the
> relative "distance" between the jobs.
>
> The first attached patch adds a InstanceId class that encapsulates the
> identifier maintenance logic. The second shows how the new class can be
> used in the existing code.
>
>
> Beside the general review, here are a few specific discussion points:
>
> We can force hex formatting for printed ID values. This will shorten
> printed IDs, but will also make them a little bit more difficult to
> find/see in the logs. Please let me know whether you think we should use

> hex.
>
> We can also move custom "created/destructed" debug messages to
> InstanceId, but I am not sure that is a good idea because it will either

> remove constructor parameters from those lines or will force us to use
> two debugging lines per constructor (one standard and one custom). I
> think it is better to add global functions to standardize output prefix
> than ask InstanceId to emit "created/destructed" debug messages. What do

> you think?
>
> Currently, InstanceId uses "int" to store ID values. I am not aware of
> any classes that need unique IDs with storage types other than int
> (e.g., to save space or further minimize wrapping). If there are such
> classes, we need to make the storage type into a second template
> parameter. Please let me know if you know of such classes.

I agree int should be enough. Especially since this usage is friendly to
wrapping values.
If there are any problems that can easily be altered to int64. Same deal
with hex display.

+1.

Amos
Received on Thu Sep 30 2010 - 02:24:31 MDT