On Wed, Oct 08, 2014 at 03:48:30PM +0200, Axel Dörfler wrote: > Am 08.10.2014 15:17, schrieb pulkomandy@xxxxxxxxxxxxx: > > * Since the BMessageFormat instances are now reused, add locking to > > avoid race conditions (ICU itself is thread safe, but the format pattern > > is recreated when the locale is changed) > > IMO format objects should be as cheap as possible, and therefore should not > perform any locking if possible. They also should not switch language > automatically; they should really be immutable objects after construction. I think that's only moving the problem around. With the current system, applications can keep track of their BMessageFormat instances, and reconfigure them when they receive a B_LOCALE_CHANGED message. The reconfiguration involves changing the language and changing the format pattern (by calling B_TRANSLATE again to get the new pattern). This is not done automatically but applications can set it up. If we remove the lock and make the objects immutable, the applications will instead have to delete their formatting objects and recreate them. To avoid any access to the object while it is being deleted and reconstructed, the locking would need to be done externally, on the application side. I must say that B_LOCALE_CHANGED didn't meet much success outside of FirstBootPrompt, so maybe it isn't worth the effort and we should drop that and make everything immutable again. We can also use a readers/writer lock to reduce the lock contention, but I think that's overdoing things. And there will be regular locking on ICU side anyway so it may not even bring us anything. -- Adrien.