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 <[email protected]> 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" <[email protected]> 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" <[email protected] >> > <mailto:[email protected]>> 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 : [email protected] >> > <mailto:[email protected]> >> > > Unsubscribe : https://launchpad.net/~kicad-developers >> > > More help : https://help.launchpad.net/ListHelp >> > > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > Post to : [email protected] >> > <mailto:[email protected]> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Mark _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
