kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

I think we will want to use threading in more places going forward in order
to enable more powerful features without hurting GUI responsiveness.
I am in favor of exploring any solutions that make it easier to use threads
-- as Jeff mentioned, the problem I'm tackling now does not relate to
globals.

On Wed, Apr 3, 2019 at 10:28 AM Jeff Young <jeff@xxxxxxxxx> wrote:

> Hi Brian,
>
> The globals wouldn’t be so bad.  It’s the EDA_TEXT’s m_Text field that’s
> the biggest issue.  Protecting that would mean no longer returning a
> reference from GetText().  But that might not be so terrible….
>
> FWIW, Kicad does use wchar_t everywhere it fetches or sets a wxString.
> It’s just the internal encoding of wxString that’s UTF-8.  (Switching
> mostly just means a compile flag — but I agree it’s bound to turn up some
> bugs.)
>
> Cheers,
> Jeff.
>
>
> > On 3 Apr 2019, at 15:05, Brian <lotharyx@xxxxxxxxx> wrote:
> >
> > My $0.02: Is shifting the whole of kicad to wchar_t (along with all the
> necessary conversions to/from multibyte for IO) easier than wrapping some
> globals inside locks for thread-safety?  Having dealt with an application
> that uses ASCII, UTF-16, and UTF-8 in various contexts (my day job), I can
> say honestly that it’s a bit of a pain in the neck. What would break if
> these global strings were protected by FCFS locks?
> >
> > -Brian
> >
> >> On Apr 3, 2019, at 9:35 AM, Jeff Young <jeff@xxxxxxxxx> wrote:
> >>
> >> 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 in).
> >>
> >> 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
>
>
> _______________________________________________
> 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
>