Hi Tom, thanks for your point of view - I'm guessing I've missed that you're working already on your variant of boost::context. This is of course a feasible way. I'm not the biggest fan of that either, because the (low level) assembler code has to be maintained, tested on all platforms, but as long as you can guarantee that it works always, it should be good. I've reviewed also the tool code and I've found there not such a huge demand to have coroutines, they're "nice to have". -- I've used protothreads for some embedded projects, you're right they look "uglier" and are sometimes a bit tricky - but easier than state machines to write. The Contiki OS is based on them. The comment about the stability was related to the implementation of the coroutine itself and is a *subjective impression*, it's of course true that it can't prevent a segfault somewhere else. -- I can of course test your code, I'll use the "stress test" for that :):) Thanks, Torsten
Many thanks for your work. I'm not particularly thrilled about stackless coroutines for the reasons below: - They would require a major rewrite of the tool code. If we were to rewrite it, I'd rather drop coroutines completely. - Performance is not an issue. The tools just handle UI events. protothreads library was invented for asynchronous I/O, where performance is critical. In Kicad, coroutines overhead is minimal. - They are based on macros, which not only means strange-looking (not to say ugly) code, but is also hard to debug. - I can't agree that if something goes wrong, the stackless coroutine will just exit, but a stackful one will crash. If there's a segfault, you'll get a crash independently of the coroutine implementation. Back to the original issue: Boost::context stopped working on MSYS2. The reason is Boost developers don't want to use GNU assembler on Windows, and the GNU asm port of the context switching functions is not the same as the MASM one (since the authors have changed the context ABI at some point). We shouldn't play cat and mouse with Boost devs by maintaining MSYS patches that won't get accepted into official Boost tree. I've been working recently on a library [1] derived from Boost::context, but which can be easily added to any C++ project, as it consists only of 2 files (.h and .cpp), just like ClipperLib, which we successfully used for processing polygons. Libcontext contains all Boost::context switching functions converted to inline assembly, with compiler and ABI detection. So far, it has been tested on: i386/x86_64 Linux, Win32/Win64 (GCC) and OSX (both 32 and 64-bit) - so all the platforms Kicad runs on are already supported (I'll also enable ARM support - as soon as I have a working test program a raspi). I think this should be sufficient for the foreseeable future. Best, Tom [1] https://github.com/twlostow/libcontext _______________________________________________ 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
