[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: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 09 Oct 2014 10:18:59 +0200
Am 09/10/2014 09:53, schrieb Adrien Destugues:
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.
Not really:
First of all, changing the locale is a very rare use case compared to
formatting. Second of all, it's very common that this will all happen in
the same thread, ie. the window owns the format, and will have to be
locked when updating the locale anyway.
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.
It doesn't have to stay that way; in any case, it doesn't make any sense
to drop it.
Everything *IS* immutable anyway. You'll have to update it manually when
you want it (usually only when you receive that event).
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.
Locking is expensive, and should be avoided whenever possible.
If Tracker formats its date column a thousand times, it should not have
to lock for that at all. That's the use case you have to optimize for.
It's also not exactly an uncommon use case to create the format on the
fly, and then apply it a thousand times. I would even assume that
storing the format won't happen that often.
Bye,
Axel.
Other related posts:
