RE: proposal for ICU tracing

Tex,

> OK, I missed the connection between the storage type and
> optionality of the
> function.
> If so, that's great.
> I'll have to look at TLS to see how that happens.

I suspect that when you turn on the trace you will pass a call back routine.
If stored in the TLS it can still be the same code for all threads or
different if you have different callbacks for different traces.

The TLS is transparent to the application because applications that do not
use threads will use a common structure in static storage.  This code also
can mask the differences between POSIX and Windows TLS handling.

I suspect that if you try to actually write a trace handler it will be
difficult because how will you report the trace info?  If you have a call
back address are you going to rewrite 20 layers of ICU calls to pass the
trace data?  Will you have a global files with mutex locking and require
that the application merge the information with the other trace data?  How
will that work in an environment that does not support standard file I/O
like Apache?  I had ICU lock up doing I/O when it processed its own bundles
under 1.4.  You have to be able to use the common code without invoking any
files.

With TLS you can access it from any point in your code that supports an
extern.  You can write a common trace routine and call it from any code.
Implementation requires almost no change to the old ICU code.  Wherever you
want to do a trace just call the trace module.  If the trace is active it
will proceed and it not it will not.

You can have a global that will compile ICU without traces to run faster but
the overhead should be minimal and the rest of the code should not change.
The nice thing about TLS is that you can find it from any point in the code
even though it may contain thread specific data so you do not have to add
overhead to the code that does not support tracing.

Carl