kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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.chris@xxxxxxxxx> 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@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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>