ICU4C Initialization

This is a proposal to change the way the ICU library is initialized.

Here is some background, describing the way ICU works now, and why we are
thinking about changing it.

Today (version 2.6), ICU is initialized as follows:

1.  At process static initialization time, mutexes are created
    that are subsequently used during the lazy initialization
    of the rest of ICU.

2.  An application may optionally call u_init() before
    using other ICU functions.  This will do the mutex init
    from step one on platforms where static init is not
    reliable, and will load ICU's data.  Use of u_init() is
    mandatory on certain multiprocessor systems.

3.  Any additional initialization for each ICU service is
    done on demand, at the time that service is first used.


There are two problems with this arrangement -

1.  For ICU 2.8, we will be introducing a mechanism to allow
    applications to replace the memory heap and mutex
    implementations that is used by ICU.  (I'll post a detailed
    proposal for this shortly).

    Static initialization will become a problem for environments
    that want to use alternative mutexes or heaps, because
    it (static init) happens before the application will have a
    chance to specify the alternate heap/mutex implementations
    to be used.

2.  In some configurations, thread safe initialization of ICU
    already requires the use of u_init().  The potentially affected
    ICU services are Normalization and Character Properties, and
    affected machine configurations are multiple processor
    systems using Alpha, Power 4 or Itanium CPUs, but not x86.

    Macintoshes also require u_init(), because C++ static init
    is not reliable.


This proposal is to require the use of u_init() in all cases, and to enforce
this requirement by returning an error if an attempt is made to use ICU
services before u_init() has been called.  All C++ style static
initialization would be removed from the ICU library.

This would be a breaking change for applications that do not already call
u_init(), so it's not something that we want to do without careful thought.
Preventing potential threading problems is a major consideration; it's
better to catch these problems early, even if this causes a little extra
work for some developers who would not otherwise be affected.

  -- Andy Heninger
     [email protected]