← Back to team overview

kicad-developers team mailing list archive

Re: More wxString multi-threading issues


Hi Tom,

I’m pretty sure it's any iterator, not just a non-const one.  And they’re used internally for things such as Length() and IsEmpty().

I wonder if you could do the mutex locking inside KiString, though?  Or would that kill performance?  (You could avoid it on Length() and IsEmpty() by caching the length and re-calculating it when written to.)


> On 3 Apr 2019, at 16:59, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx> wrote:
> On 03/04/2019 17:42, Wayne Stambaugh wrote:
>> I would be reluctant to get behind this just because of the possibility
>> of epic string breakage on lot's of levels.  If there was some way to
>> piece meal this transition, it might be more palatable but that may
>> prove to be very difficult.
>> The need to use threads, is less clear.  It may be far less problematic
>> to start the netlist rebuild during idle time and break out of the
>> netlist loop use wxApp::Yield() and mark it as incomplete when a user
>> event that requires attention is generated.  I know this is somewhat
>> less elegant than threads but it does resolve the wxString issue.
> How about deriving some sort of "KiString" class from wxString, but with
> disabled (private) non-const iterators and other methods that are non
> thread-safe (IIRC it was the non-const iterator).
> class KiString : public wxString {
> 	private:
> 	  iterator begin() {};
> 	  iterator end() {};
> };
> This should drop an error if the user attempts to use non-thread-safe
> features of wxString...
> Cheers,
> Tom
> _______________________________________________
> 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