Re: [boost] [iostreams][io_state_savers] Request for interest in some ios_base basic utilities

Subject: Re: [boost] [iostreams][io_state_savers] Request for interest in some ios_base basic utilities
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-11-10 08:05:35

Artyom Beilis wrote:
> 
>> From: Vicente Botet <vicente.botet@>
>> 
>> Artyom Beilis wrote:
>>> 
>>>  ----- Original Message -----
>>>  Also it can be extended with some new styles easily if needed like
>>>  for example "duration" style.
>>> 
>>>  So I'd suggest to use them.
>>> 
>> 
>> I'll take a look, but I don't think that I will be able to use the
>> Boost.Locale manipulators, as the intents is to make a proposal for the
>> standard, so dependence on other libraries should be minimized at least
>> at
>> the interface level.
>> 
>> 
> 
> Actually I'm planning to do some proposals with Boost.Locale but I see
> your
> point.
> 
>> 
>>>  For example xalloc is thread safe in both MSVC and GCC libraries.
>>> 
>> 
>> 
>> I don't like this kind of design, which forces the user to initialize the
>> library. I will expect we can do better.
>> 
> 
> Global constructor?
> 

I don't see what you mean.

>>>  I don't know if chrono is header only library or not.
>>> 
>>>  Just you need to make sure that such library can't be header only.
>>>  As long as it is not header only there will be no such problem.
>>> 
>> 
>> Well I spent some time to make Boost.Chrono header only. I will be a
>> little
>> bit disappointed if I can not make a library that uses standard I/O
>> thread
>> safe other than using some tricks that can not be used in a header only
>> library.
> 
> The problem is rather inter module access rather then thread safety issue.
> And inter module access (cross dll) you can't do without library part
> under DLL platform... 
> 
> And singleton can't be done in header only library under dll platform as
> well.
> 

Isn't Boost.Flyweight a header only library?

> So... It is problem. However it is not problem for standard
> submission as you always have library - standard c++ library which
> by no means can be header only.
> 

Well for the standard submission there is thread or module issue if this
state is included directly on the ios state and the default facet is already
imbue with the associated facets ;-). Of course this is something I cannot
do with Boost.Chorno, or I don't know how to do it :'(.

>>>  For example all locale ids and all xalloc ids are initialized once
>>>  globally.
>>> 
>>> 
>> 
>> Beside the static data initialization, how do you ensure the access (R or
>> W)
>> to the ios state flags and locale facets are thread safe? Are you using a
>> mutex?
>> 
> 
> Locale facets, once installed are immutable objects. So they become 
> thread safe by immutability(*) as they either operate on constant
> data.
> 

Yes I see. Only the facet id is concerned by multi-threading.

> Now ios state flags should not be thread safe as they stream specific
> and I don't expect from user to alter iostream flags from different
> threads.
> 
> (*) With ICU not all facets are immutable so in some places I use TLS to
> Â Â Â  improve performance as for example with collator.
> 

Why do you need mutable facets? Isn't this against the locale/facet design?

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/iostreams-io-state-savers-Request-for-interest-in-some-ios-base-basic-utilities-tp4020844p4023525.html
Sent from the Boost - Dev mailing list archive at Nabble.com.