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
