kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

You can just use wxPostEvent which is already thread-safe to pass
"events" back to the progress dialog.

On Mon, Jan 11, 2016 at 9:36 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
> 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
>> >
>
>
> _______________________________________________
> 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
>



-- 
Mark