Re: proposal for ICU tracing

Thanks Carl, It is much clearer now.

This is one approach. We should see what the ICU team had planned.

tex

"Carl W. Brown" wrote:
> 
> 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
> 
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:[email protected]
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------