kicad-developers team mailing list archive
Mailing list archive
Re: More wxString multi-threading issues
I’m currently trying a build with no wxString reference in that particular spot, and overriding the routine at the SCH_FIELD level to lock a mutex when copying the string to the stack. I’ll email again once I have results….
(Note however that this is a piecemeal approach: we’d still have to find all things affected and guard them with mutexes. It just keeps the guard from “escaping” through a returned reference.)
> On 3 Apr 2019, at 16:15, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> Hi Jeff-
> The major downside to our using UTF-16 is that it is not endian-independent. Unless we drop support for big-endian platforms, we'll need to handle both cases. I needn't tell you what a pain that would be.
> Maybe we can just not return wxString references? Enforce a getter/setter paradigm and pass the object?
> Am 2019-04-03 09:35, schrieb Jeff Young:
>> Jon is currently fighting another wxString multi-threading issue.
>> Having done quite a few of these myself, I feel for him.
>> A lot of them were threaded accesses to globals, so it was easy enough
>> to make the globals std::strings. However, this one is EDA_TEXT’s
>> m_Text field. That’s going to be a pretty big change to move to
>> std::string. And it’s nearly impossible to compartmentalise because
>> returning a const& isn’t really const (iterating over the string will
>> modify the linked-list of iterators, which is where the trouble comes
>> What about moving Kicad to UTF16 internally? (The linked list of
>> iterators is a performance optimisation specifically for UTF8 builds.)
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp