RE: proposal for ICU tracing

Tex,

With TLS is greatly simplifies the trace code.

To start tracing you find the TLS and turn the trace flag on and set that
callback address and user thread specific data structure.

To invoke a trace point anywhere in the ICU code there is not need to make
any change other than call the trace routine which gets the TLS and if the
trace flag is set it builds a parameter list and calls the callback routine
including both ICU trace data and the user thread specific data structure.

To stop tracing you get the TLS and turn off the trace flag,

The trace can be dropped anywhere into the ICU code with no special changes.

The user in his trace callback routine can do whatever they want.  Often
lager application have proprietary trace routines, these can be invoked.  If
not many systems have systems trace functions.  The application may want to
check for expected results and only take action if they are unexpected.

As I mentioned earlier some of the ICU code does not have consistent error
code handling especially between C and C++ code.  This would allow
implementation and tracing without redoing any of the code.

Carl


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Tex Texin
> Sent: Monday, November 03, 2003 10:19 PM
> To: Carl W. Brown
> Cc: [email protected]
> Subject: 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
> -------------------------------------------------------------
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>