RE: ICU tracing and thread locale storage

George,

Take this example.

I have a transaction processing system that is failing to format dates on
some transactions.  I know where the code that calls udat_open and now that
it is failing but I have no idea why.  I get a U_MEMORY_ALLOCATION_ERROR so
I know that createDateTimeInstance is failing.  I have looked at it but
there is a lot of code under the covers but none of it returns and kind of
error codes and I have no idea of just where it is failing.  I do not want
to trace the world.

If tracing is implemented at a global level I will get millions of trace
events for all over ICU to sift though and have no idea of which one are
applicable to my transaction.

I want to enable tracing just for that call to ICU.  I would also like to
pass some data so that the trace callback can identify the trace in a way
that is meaningful for my application so that I can keep traces for
different transactions straight.

If I have a trace flag I must have one that is thread specific.  I can pass
the flag but to do that I have to change the udat_open API to handle a new
parameter.  But that is not enough because I also have to change
createDateTimeInstance as well.  And so it goes until every API is changed.
That is a tremendous amount of very disruptive work.

If you implement flags using TLS you can design to code so that thread
unique values can be accessed for anywhere in the code without changing a
single API.

If they do not need tracing the user application code will not have to be
changed.  If they need tracing they will have to invoke ICU code at thread
initiation and termination as well as trace control calls.  They will also
have to provide one or more trace callback routines.

This make it easy to drop traces anywhere in to the ICU code and provide a
simple compile switch to remove tracing support.

If you look at the xIUA code you will see how easy it is to write support
that will work with Windows, POSIX and non-threaded environments.

Carl