[haiku-commits] Re: haiku: hrev47984 - src/kits/locale src/servers/mail src/kits/tracker headers/os/locale src/add-ons/mail_daemon/inbound_filters/notifier
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 9 Oct 2014 09:53:48 +0200
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.
Other related posts:
