kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/15/2013 01:46 PM, Miguel Angel Ajo Pelayo wrote:
> On 15/03/2013, at 19:32, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>
>> On 03/15/2013 11:39 AM, Miguel Angel Ajo Pelayo wrote:
>>> Ok, committed in 4008, cleanups included. 
>>>
>>> Finally I used the LOCALE_IO implementation, because converting in
>>> some situations didn't work, and my time was exhausting for today…
>>>
>>> I think there are some locale manipulators in std:: c++ that would
>>> let us do those conversions without switching system locale, but we will have to try.
>>
>> We don't have to try.  We could wait until there is a problem.
>>
>>
> I feel like planting bombs around ;)
>
>
>> If or when there is a problem, I would fight to protect the interfaces
>> we have become dependent on, one of which is OUTPUTFORMATTER::Print().
>> You shouldn't try to re-implement this without my help.
>>
> In vsnprintf (used in OUTPUTFORMATTER::vprint) is affected by locale too, right?,
> You mean that on locale changes we should protect those call?


Yes, so that means OUTPUTFORMATTER::Print() is not thread safe
currently, an implementation characteristic.  Not an interface problem
per se.


>
>
>
>> Writing good C++ software is really about placing and using carefully
>> crafted interfaces.   After that you can ad lib in between the
>> interfaces, so long as you honour them.
> Yes :)
>
>>
>> A C++ thread can be like the quirky guy who walks up the stairs of a
>> skyscraper, travelling across each floor and then back into the
>> stairwell to continue ascending.
>>
>> When he travels across each floor, he is wearing the proper attire and
>> acting properly.  This is the interface. 
>>
>> But in the stairwell he very well may be acting quite differently,
>> nobody knows, nobody cares.   Could be naked in there, could be
>> walking on his hands, screaming, yelling.   This is the implementation.
>>
> Good simile, 
>
> Yes, I know the problem, and the GIL python think made me remember that one
> must not forget, reentrancy, and thread-safety are your friends!!
>
> In pcbnew, I cannot imagine yet a situation when all this could happen, somebody printing a report somehow, while hits a key 
> or writes a file?, sounds quite improbable. But yet I'm sure there are possibilities we didn't think of… or not.. :)

Currently only when python is in play could this happen, and only when
somebody uses it to create additional threads.

Python has its own implementation of snprintf(), probably to be able
to dodge locale issues like this one, but also to give perfectly
consistent formatting across platforms, where Windows' use of
msvcrt.dll is a bit off.



>
>
>
>> It pays to know which part of the C++ thread you are dealing with.  
>> Saves some embarrassment, and makes for better and more easily
>> maintained code.  Because you can always smoke bomb the implementation.
>>
>
> Is OUTPUTFORMATTER to be used for tasks like the one I was dealing with above?,  printing a %lf to a string?,
> For the name, it looks like a class to be used when dealing with file writing, didn't have enough time to look inside yet.

workable, but not thread safe currently:

wxString DoubleString( double d )
{
    IO_LOCALE         toggle;
    STRING_FORMATTER  sf;

    sf.Print( 0, "%g", double );

    return FROM_UTF8( sf.GetString() );
}



or simpler, still not thread safe:

wxString DoubleString( double d )
{
    IO_LOCALE   toggle;
    char        buf[100];

    sprintf( buf, "%g", double );

    return FROM_UTF8( buf );
}



The motivator for me to have chosen the printf() style output
formatting is I find it easier to use, easier to read, with great
specificity, and is leaner in terms of fewer function calls than C++
output formatting streams.

Each one of those << operators is another function call, and I don't
like the in line usage of formatting, which is slower and more
awkward, and retentative.


To get thread safe behaviour in the OUTPUTFORMATTER and family, I
would re-implement sprintf() and friends, re-entrantly, and teach it
to ignore locale.   I have done this before, and the cost is not
trivial, therefore my remark about "we don't have to, until we have
to".  Some things are worth procrastinating when the risk of
procrastinating is low.