[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: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 09 Oct 2014 12:54:55 +0200
Hi,
Am 09.10.2014 12:40, schrieb Adrien Destugues:
On Thu, Oct 09, 2014 at 11:35:35AM +0200, Axel Dörfler wrote:
Am 09/10/2014 11:17, schrieb Adrien Destugues:
It still needs locking, no matter how rare.
Why would it need any locking?
Well, either locking or "only use in a single thread".
It is perfectly normal that various Be API objects are not thread-safe.
BString, BList, etc. are all not threadsafe. I think most of them are
not. But that doesn't mean you can't use them from multiple threads, you
just have to take care of locking yourself - *if* that is your use-case
at all. As Axel explained, the normal use-case would not be to use these
objects from different threads (in which case thread-safety would be a
convenience). And then the performance impact of the unnecessary locking
in the normal use-case is really not what you want.
Since BCatalog::GetString also has a lock, that's not true. This one is
definitely needed for B_LOCALE_CHANGED to work, as the catalog is
application-global and we can't assume a BLooper lock is enough to
safely access it (the catalog is immutable, and on locale changes it is
deleted and a new one loaded from disk).
This sounds really broken. The application should be notified about the
locale change (as is the case), but then it needs to be up to the
application to act on the change, including the triggering of re-loading
the catalog. What good is it if a string changes underneath the app, but
the app has not updated (the rest of) the UI? In the best scenario, you
get a mix of different languages in the UI, in the worst case, you have
cut-off labels.
The translation can still be done once, and BMessageFormat created
on-demand anyway. However I'm worried about the initialisation of the
BMessageFormat object not being a cheap operation, as it needs to parse
the format string, and create instances of PluralFormat, ChoiceFormat,
or anything else required by it. This involves several memory
allocations which I think are better to not repeat.
I can make the B*Format immutable, and remove the locking. But these
situations will still have to be handled on the application side anyway.
Yes. I think the sensible thing is to make them immutable, and let the
application handle the rest. Otherwise you have too many assumptions
that might be wrong depending on the application.
It only adds the "lazy" option of using the object only in a single
thread, which has some use cases (when formatting thousands of items).
Actually it sounds like it would avoid a lot more potential problems.
Best regards,
-Stephan
Other related posts:
