My point is that threading could be used to implement a *drop-in replacement*...not that the tool framework should be structured around them, but that it continues to use coroutines, and we make a coroutine library that is implemented using threads... :P
On Wed, Mar 01, 2017 at 04:32:39PM -0500, Wayne Stambaugh wrote: > We all have our preferred solutions the problem at hand. I personally > didn't see any reason to not use events. I have a sneaking suspicion > that the context switching was done to isolate the coder from having to > deal with events directly which on the surfaces seems like a good idea > but causes it's own set of design issues when executed within an event > driven application. My preference would have been to have the tool > objects be derived from wxEventHandler (or abstracted out to work with > different event systems) and inserted between the canvas and the main > window event handler on the wxWidgets event handler stack. Since no one > else stepped up to resolve the issues, the person who resolved them wins. ;) > > On 3/1/2017 12:01 PM, Chris Pavlina wrote: > > I know I've suggested this before and been shot down, but I'm still > > pretty convinced a coroutine library could be made that makes use of > > native threading support. This would be totally portable to all > > platforms! > > > > I don't have the time to POC it myself, I already have a kicad todo list > > miles long. But it seems to me that if we were to spawn a thread for > > each coroutine, lock them all to the same core via CPU affinity to avoid > > any caching issues, and use a global lock and simple scheduler to > > interleave the coroutines (i.e. when a coroutine yields, it really sets > > a lock and waits for it to unlock), it should work just fine.. > > > > On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote: > >> That's the one is was thinking about! AArch64 is coming fast so we only > >> do ourselves a disservice by not supporting it. In fact, there is now a > >> aarch64 device available designed with KiCad. It would be ironic if > >> KiCad couldn't run on it due to lack of support. SPARC and PPC may not > >> be main stream but if we can support them by using an already vetted > >> library, than that is my preference. > >> > >> On 3/1/2017 10:25 AM, Chris Pavlina wrote: > >>> Ah, crap. Missed that. Don't think I have one lying about anymore to > >>> volunteer... :( > >>> > >>> On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote: > >>>> On 01.03.2017 16:19, Chris Pavlina wrote: > >>>>> Wayne *please* tell me you won't block something that fixes macOS > >>>>> support and eliminates future boost API problems (which we've had > >>>>> SEVERAL problems with in the past) because of a lack of support for > >>>>> bloody *SPARC and PPC*. If there is a single user using KiCad on these > >>>>> platforms I would like to see them. > >>>>> > >>>> Hi Chris, > >>>> > >>>> Boost does support aarch64, I just lack a compiler/machine to test > >>>> that... > >>>> > >>>> Cheers, > >>>> T. > >>>>> Now, the lack of support for aarch64 is a disappointment, but it looks > >>>>> like boost currently doesn't support that either. > >>>>> > >>>>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote: > >>>>>> On 01.03.2017 15:58, Wayne Stambaugh wrote: > >>>>>>> I am in favor of this if and only if we have equivalent or better > >>>>>>> architecture coverage compared to the boost context library. If not, > >>>>>>> than I am opposed to it. > >>>>>>> > >>>>>> Hi Wayne, > >>>>>> > >>>>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not > >>>>>> test the sparc/PPC ports for obvious reasons. I could add linux > >>>>>> sparc/PPC support but without testing, since I don't have a suitable > >>>>>> machine. > >>>>>> > >>>>>> For the moment, libcontext works on every OS/CPU we officially support. > >>>>>> > >>>>>> Cheers, > >>>>>> Tom > >>>>>> > >>>>>> > >>>>>>> On 3/1/2017 9:32 AM, Chris Pavlina wrote: > >>>>>>>> I am in favor of this. > >>>>>>>> > >>>>>>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote: > >>>>>>>>> I will do my best, but I really cannot promise any time slot for > >>>>>>>>> looking > >>>>>>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext > >>>>>>>>> [1]? > >>>>>>>>> The number of #ifdefs in tge current coroutine code makes eyes pop > >>>>>>>>> out, > >>>>>>>>> and I am afraid with the new issue we would be forced to add "#ifdef > >>>>>>>>> __APPLE__" to this horrible mess. > >>>>>>> > >>>>>>> This probably could have been hidden using cmake. It typically takes > >>>>>>> more effort to do it this way but it results in cleaner source code. > >>>>>>> > >>>>>>>>> > >>>>>>>>> This way we should be immune to future boost::context changes. The > >>>>>>>>> drawback is, we are on our own if there is a new architecture to > >>>>>>>>> support. On the other hand, how often a new architecture becomes > >>>>>>>>> popular > >>>>>>>>> enough to care about it? > >>>>>>>>> > >>>>>>>>> To sum up: I would switch to libcontext and stop worrying. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Orson > >>>>>>>>> > >>>>>>>>> 1. https://github.com/twlostow/libcontext > >>>>>>>>> > >>>>>>>>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote: > >>>>>>>>>> This is a known issue. I believe the last valid version of boost > >>>>>>>>>> that > >>>>>>>>>> doesn't cause a crash is 1.61. Anything after that causes this > >>>>>>>>>> issue on > >>>>>>>>>> all platforms not just osx. @Orson or @Tom, any chance you could > >>>>>>>>>> take a > >>>>>>>>>> look at this to see what boost changed in the context library? > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> > >>>>>>>>>> Wayne > >>>>>>>>>> > >>>>>>>>>> On 2/23/2017 6:49 AM, Simon Wells wrote: > >>>>>>>>>>> just fyi > >>>>>>>>>>> > >>>>>>>>>>> https://bugs.launchpad.net/kicad/+bug/1658249 > >>>>>>>>>>> > >>>>>>>>>>> On 24 February 2017 at 00:38, Chris Pavlina > >>>>>>>>>>> <pavlina.ch...@gmail.com> wrote: > >>>>>>>>>>>> Backtrace attached. Boost is 1.63.0. > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote: > >>>>>>>>>>>>> Hi Chris, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Would you give more details about the problem? Boost version, > >>>>>>>>>>>>> backtrace? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> Orson > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due > >>>>>>>>>>>>>> to a null > >>>>>>>>>>>>>> dereference in the coroutine code: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> coroutine.h > >>>>>>>>>>>>>> 408 static CONTEXT_T callerStub( CONTEXT_T caller, > >>>>>>>>>>>>>> INVOCATION_ARGS* aArgsPtr ) > >>>>>>>>>>>>>> 409 { > >>>>>>>>>>>>>> 410 const auto& args = *aArgsPtr; > >>>>>>>>>>>>>> 411 auto* cor = args.destination; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> aArgsPtr is null and I don't understand WHY. However, I was > >>>>>>>>>>>>>> able to make > >>>>>>>>>>>>>> things appear to work by short-circuiting this function if the > >>>>>>>>>>>>>> argument > >>>>>>>>>>>>>> is null. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Patch attached. It Works For Me™, but I'd like someone who > >>>>>>>>>>>>>> knows the > >>>>>>>>>>>>>> coroutine code to look and make sure I haven't made a mess of > >>>>>>>>>>>>>> things. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
