kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Multiple threads updating the progress isn't hard, it's just basic thread
synchronization. A few ideas:

Each thread object has a method to query its individual progress. This
method performs synchronized or atomic access to a member variable holding
a progress value, and the master thread polls these. Decent if you just
want a percentage (if done correctly, a single small number can be written
atomically with no separate synchronization to slow things down).

Each thread object pushes progress update objects to a central synchronized
queue structure. Best if you want to get status messages too. Master thread
sinks messages from the queue and pushes them to the GUI.

Surely one of the libraries we're using has a thread-safe queue? If not
it's trivial to implement with a vector and mutexes.

(Side note: my phone /really/ wanted to say "a vector and murders" above. I
do not recommend this approach, though I see how it could work.)
On Jan 11, 2016 09:24, "Wayne Stambaugh" <stambaughw@xxxxxxxxx> wrote:

> On 1/11/2016 9:09 AM, Chris Pavlina wrote:
> > I have to say, I really agree about the worker threads. I'm not sure why
> > we even took the time to code that - it's almost never useful and, as
> > Mark says, can cause issues. Personally I'd love to see that ripped
> > right out, or at least the number of threads set to 1 by default.
> > There's a reason nobody else does this anymore.
>
> It wouldn't be terribly difficult to make this a build configuration
> option that defaults to one.  This way users who absolutely must have
> multi-threaded github access can still enable it.  The only problem
> might be updating a progress dialog using multiple threads.  Better yet,
> use wxWidgets idle time to down load a least the footprint names in the
> background so they are ready for use when the user finally does get
> around to using them.  IFAIK we currently only load and cache the
> footprint names.  The actual footprint is loaded on demand.
>
> >
> > And yeah, there needs to be a progress display of some sort for loading
> > libraries. Not just downloading from Github either, IMO! I've got a
> > library on disk that is very large, and it makes things feel rather
> > rough around the edges when KiCad freezes up for ten seconds or so
> > trying to load it...
> >
> > On Jan 11, 2016 08:59, "Wayne Stambaugh" <stambaughw@xxxxxxxxx
> > <mailto:stambaughw@xxxxxxxxx>> wrote:
> >
> >     On 1/10/2016 7:49 PM, Mark Roszko wrote:
> >     > Just a heads up as I fix this, there's a race condition with how
> >     > libcurl in KiCad is implemented on Windows involving openssl.
> >     >
> >     >
> >     > Turns out openssl being as trashy as it is has all kinds of thread
> >     > safety issues without linking against it directly and doing
> something
> >     > stupid (use its own locking functions) at thread level. I don't
> want
> >     > to know why they have issues even doing a sha512 hash separately in
> >     > threads, it's just ridiculous.
> >     >
> >     >
> >     > OSX which no longer uses openssl isn't affected. Linux distros with
> >     > openssl based libcurl are affected but theres many distros now
> using
> >     > ntls or gnutls in place of openssl. So only windows users may be
> >     > getting an ~occasional crash.~
> >     >
> >     >
> >     >
> >     > My proposed solution:
> >     > 1. Toss concurrent downloading out the window. It's a horrible
> idea.
> >     > No package manager does this (apt, yum, Steam, Windows Update,
> etc).
> >     > You risk tripping firewalls and just split your bandwidth over
> >     > multiple connections. You can even peg your CPU with the https
> >     > overhead attempting to do it simultaneously on 40 separate
> >     > connections. Actually on that note, they'll block each other if you
> >     > exist your system entropy on Linux momentarily.
> >
> >     This is easy enough to do by disabling the worker threads in
> >     common/footprint_info.cpp.
> >
> >     >
> >     > 2. Add a "update progress" UI, its completely stupid that when you
> >     > open CVPCB that it silently tries to update your 30+ libraries in
> the
> >     > background with no indication. This is really bad on users on bad
> >     > connections.
> >
> >     Single threading would make this much more doable.
> >
> >     >
> >     > _______________________________________________
> >     > Mailing list: https://launchpad.net/~kicad-developers
> >     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto: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
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     More help   : https://help.launchpad.net/ListHelp
> >
>